[prev in list] [next in list] [prev in thread] [next in thread]
List: postgresql-general
Subject: Re: [HACKERS] Adding support for Default partition in partitioning
From: Jeevan Ladhe <jeevan.ladhe () enterprisedb ! com>
Date: 2017-06-30 12:30:53
Message-ID: CAOgcT0Nce6zfMstXP4aoZ3SOQA8ceC5ecG7KV1KwEWW2NBWDRQ () mail ! gmail ! com
[Download RAW message or body]
Hi,
On Mon, Jun 19, 2017 at 12:34 PM, Amit Langote <
Langote_Amit_f8@lab.ntt.co.jp> wrote:
> On 2017/06/16 14:16, Ashutosh Bapat wrote:
> > On Fri, Jun 16, 2017 at 12:48 AM, Robert Haas <robertmhaas@gmail.com>
> wrote:
> >> On Thu, Jun 15, 2017 at 12:54 PM, Ashutosh Bapat
> >> <ashutosh.bapat@enterprisedb.com> wrote:
> >>> Some more comments on the latest set of patches.
> >> or looking up the OID in the
> >> relcache multiple times.
> >
> > I am not able to understand this in the context of default partition.
> > After that nobody else is going to change its partitions and their
> > bounds (since both of those require heap_open on parent which would be
> > stuck on the lock we hold.). So, we have to check only once if the
> > table has a default partition. If it doesn't, it's not going to
> > acquire one unless we release the lock on the parent i.e at the end of
> > transaction. If it has one, it's not going to get dropped till the end
> > of the transaction for the same reason. I don't see where we are
> > looking up OIDs multiple times.
>
> Without heap_opening the parent, the only way is to look up parentOid's
> children in pg_inherits and for each child looking up its pg_class tuple
> in the syscache to see if its relpartbound indicates that it's a default
> partition. That seems like it won't be inexpensive either.
>
> It would be nice if could get that information (that is - is a given
> relation being heap_drop_with_catalog'd a partition of the parent that
> happens to have default partition) in less number of steps than that.
> Having that information in relcache is one way, but as mentioned, that
> turns out be expensive.
>
> Has anyone considered the idea of putting the default partition OID in the
> pg_partitioned_table catalog? Looking the above information up would
> amount to one syscache lookup. Default partition seems to be special
> enough object to receive a place in the pg_partitioned_table tuple of the
> parent. Thoughts?
>
I liked this suggestion. Having an entry in pg_partitioned_table would avoid
both expensive methods, i.e. 1. opening the parent or 2. lookup for
each of the children first in pg_inherits and then its corresponding entry
in
pg_class.
Unless anybody has any other suggestions/comments here, I am going to
implement this suggestion.
Thanks,
Jeevan Ladhe
[Attachment #3 (text/html)]
<div dir="ltr">Hi,<br><div class="gmail_extra"><br></div><div \
class="gmail_extra"><div class="gmail_quote">On Mon, Jun 19, 2017 at 12:34 PM, Amit \
Langote <span dir="ltr"><<a href="mailto:Langote_Amit_f8@lab.ntt.co.jp" \
target="_blank">Langote_Amit_f8@lab.ntt.co.jp</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><span class="">On 2017/06/16 14:16, Ashutosh Bapat wrote:<br> \
> On Fri, Jun 16, 2017 at 12:48 AM, Robert Haas <<a \
href="mailto:robertmhaas@gmail.com">robertmhaas@gmail.com</a>> wrote:<br> >> \
On Thu, Jun 15, 2017 at 12:54 PM, Ashutosh Bapat<br> >> <<a \
href="mailto:ashutosh.bapat@enterprisedb.com">ashutosh.bapat@enterprisedb.<wbr>com</a>> \
wrote:<br> >>> Some more comments on the latest set of patches.</span><span \
class=""><br> >> or looking up the OID in the<br>
>> relcache multiple times.<br>
><br>
> I am not able to understand this in the context of default partition.<br>
> After that nobody else is going to change its partitions and their<br>
> bounds (since both of those require heap_open on parent which would be<br>
> stuck on the lock we hold.). So, we have to check only once if the<br>
> table has a default partition. If it doesn't, it's not going to<br>
> acquire one unless we release the lock on the parent i.e at the end of<br>
> transaction. If it has one, it's not going to get dropped till the end<br>
> of the transaction for the same reason. I don't see where we are<br>
> looking up OIDs multiple times.<br>
<br>
</span>Without heap_opening the parent, the only way is to look up \
parentOid's<br> children in pg_inherits and for each child looking up its \
pg_class tuple<br> in the syscache to see if its relpartbound indicates that it's \
a default<br> partition. That seems like it won't be inexpensive either.<br>
<br>
It would be nice if could get that information (that is - is a given<br>
relation being heap_drop_with_catalog'd a partition of the parent that<br>
happens to have default partition) in less number of steps than that.<br>
Having that information in relcache is one way, but as mentioned, that<br>
turns out be expensive.<br>
<br>
Has anyone considered the idea of putting the default partition OID in the<br>
pg_partitioned_table catalog? Looking the above information up would<br>
amount to one syscache lookup. Default partition seems to be special<br>
enough object to receive a place in the pg_partitioned_table tuple of the<br>
parent. Thoughts?<br></blockquote><div> </div><div>I liked this suggestion. Having \
an entry in pg_partitioned_table would avoid</div><div>both expensive methods, i.e. \
1. opening the parent or 2. lookup for</div><div>each of the children first in \
pg_inherits and then its corresponding entry in</div><div>pg_class.</div><div>Unless \
anybody has any other suggestions/comments here, I am going to</div><div>implement \
this suggestion.</div><div><br></div><div>Thanks,<br></div><div>Jeevan \
Ladhe</div></div></div></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic