From: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Declarative partitioning - another take |
Date: | 2016-08-31 07:35:41 |
Message-ID: | 33442b07-f9f9-b326-78c3-70636d284246@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2016/08/31 16:17, Robert Haas wrote:
> On Wed, Aug 31, 2016 at 12:37 PM, Amit Langote wrote:
>> What I was trying to understand is why this would not be possible
>> with a design where partition bound is stored in the catalog as a property
>> of individual partitions instead of a design where we store collection of
>> partition bounds as a property of the parent.
>
> From the point of view of feasibility, I don't think it matters very
> much where the property is stored; it's the locking that is the key
> thing. In other words, I think this *would* be possible if the
> partition bound is stored as a property of individual partitions, as
> long as it can't change without a lock on the parent.
>
> However, it seems a lot better to make it a property of the parent
> from a performance point of view. Suppose there are 1000 partitions.
> Reading one toasted value for pg_class and running stringToNode() on
> it is probably a lot faster than scanning pg_inherits to find all of
> the child partitions and then doing an index scan to find the pg_class
> tuple for each and then decoding all of those tuples and assembling
> them into some data structure.
Seems worth trying. One point that bothers me a bit is how do we enforce
partition bound condition on individual partition basis. For example when
a row is inserted into a partition directly, we better check that it does
not fall outside the bounds and issue an error otherwise. With current
approach, we just look up a partition's bound from the catalog and gin up
a check constraint expression (and cache in relcache) to be enforced in
ExecConstraints(). With the new approach, I guess we would need to look
up the parent's partition descriptor. Note that the checking in
ExecConstraints() is turned off when routing a tuple from the parent.
Thanks,
Amit
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2016-08-31 07:42:14 | Re: Aggregate Push Down - Performing aggregation on foreign server |
Previous Message | Michael Paquier | 2016-08-31 07:30:34 | Re: Missing checks when malloc returns NULL... |