Re: ATTACH/DETACH PARTITION CONCURRENTLY
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Michael Paquier <michael@paquier.xyz>, Sergei Kornilov <sk@zsrv.org>, Amit Langote <langote_amit_f8@lab.ntt.co.jp>,
David Rowley <david.rowley@2ndquadrant.com>, Andres Freund <andres@anarazel.de>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
Simon Riggs <simon@2ndquadrant.com>
Date: 2019-02-01T14:00:36Z
Lists: pgsql-hackers
On Thu, Jan 31, 2019 at 6:00 PM Alvaro Herrera <alvherre@2ndquadrant.com> wrote: > > - 0003 doesn't have any handling for parallel query at this point, so > > even though within a single backend a single query execution will > > always get the same PartitionDesc for the same relation, the answers > > might not be consistent across the parallel group. > > That doesn't sound good. I think the easiest would be to just serialize > the PartitionDesc and send it to the workers instead of them recomputing > it, but then I worry that this might have bad performance when the > partition desc is large. (Or maybe sending bytes over pqmq is faster > than reading all those catalog entries and so this isn't a concern > anyway.) I don't think we'd be using pqmq here, or shm_mq either, but I think the bigger issues is that starting a parallel query is already a pretty heavy operation, and so the added overhead of this is probably not very noticeable. I agree that it seems a bit expensive, but since we're already waiting for the postmaster to fork() a new process which then has to initialize itself, this probably won't break the bank. What bothers me more is that it's adding a substantial amount of code that could very well contain bugs to fix something that isn't clearly a problem in the first place. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Commits
-
Allow ATTACH PARTITION with only ShareUpdateExclusiveLock.
- 898e5e3290a7 12.0 landed
-
Change lock acquisition order in expand_inherited_rtentry.
- f4b6341d5fcb 12.0 landed
-
Move code for managing PartitionDescs into a new file, partdesc.c
- 1bb5e7821810 12.0 landed
-
Remove more redundant relation locking during executor startup.
- f2343653f5b2 12.0 cited
-
Add assertions that we hold some relevant lock during relation open.
- b04aeb0a053e 12.0 cited
-
Try to acquire relation locks in RangeVarGetRelid.
- 4240e429d0c2 9.2.0 cited