Re: Declarative partitioning - another take
Amit Langote <langote_amit_f8@lab.ntt.co.jp>
On 2016/08/29 20:53, Robert Haas wrote: > On Fri, Aug 26, 2016 at 1:33 PM, Amit Langote > <Langote_Amit_f8@lab.ntt.co.jp> wrote: >> We do take a lock on the parent because we would be changing its partition >> descriptor (relcache). I changed MergeAttributes() such that an >> AccessExclusiveLock instead of ShareUpdateExclusiveLock is taken if the >> parent is a partitioned table. > > Hmm, that seems both good and bad. On the good side, as mentioned, > being able to rely on the partition descriptor not changing under us > makes this sort of thing much easier to reason about. On the bad > side, it isn't good for this feature to have worse concurrency than > regular inheritance. Not sure what to do about this. > >> If we need an AccessExclusiveLock on parent to add/remove a partition >> (IOW, changing that child table's partitioning information), then do we >> need to lock the individual partitions when reading partition's >> information? I mean to ask why the simple syscache look-ups to get each >> partition's bound wouldn't do. > > Well, if X can't be changed without having an AccessExclusiveLock on > the parent, then an AccessShareLock on the parent is sufficient to > read X, right? Because those lock modes conflict. Yes. And hence we can proceed with performing partition elimination before locking any of children. Lock on parent (AccessShareLock) will prevent any of existing partitions to be removed and any new partitions to be added because those operations require AccessExclusiveLock on the parent. 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. Thanks, Amit
Commits
-
Fix typo.
- 03bf59676ea0 10.0 landed
-
Document trigger-firing behavior for inheritance/partitioning.
- e17628145ac3 10.0 landed
-
Fire per-statement triggers on partitioned tables.
- e180c8aa8caf 10.0 landed
-
Set ecxt_scantuple correctly for tuple routing.
- 132488bfee68 10.0 landed
-
Fix interaction of partitioned tables with BulkInsertState.
- b1ecb9b3fcfb 10.0 landed
-
Avoid core dump for empty prepared statement in an aborted transaction.
- ba61a04bc7fe 10.0 cited
-
Fix some problems in check_new_partition_bound().
- 8a8afe2f54c2 10.0 landed
-
Remove unnecessary arguments from partitioning functions.
- 18fc5192a631 10.0 cited
-
Fix reporting of constraint violations for table partitioning.
- f1b4c771ea74 10.0 cited
-
Fix tuple routing in cases where tuple descriptors don't match.
- 2ac3ef7a01df 10.0 cited
-
Invalid parent's relcache after CREATE TABLE .. PARTITION OF.
- 7cd0fd655d68 10.0 landed
-
Doc: improve documentation about inheritance.
- 162477a63d3c 10.0 cited