From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Sergei Kornilov <sk(at)zsrv(dot)org>, Amit Langote <langote_amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Simon Riggs <simon(at)2ndquadrant(dot)com> |
Subject: | Re: ATTACH/DETACH PARTITION CONCURRENTLY |
Date: | 2019-02-01 14:00:36 |
Message-ID: | CA+TgmoY+kOiUpokCge0C0aru3B1jzaf2OgBWrKpK42TycJMVEA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jan 31, 2019 at 6:00 PM Alvaro Herrera <alvherre(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2019-02-01 14:07:37 | Re: Delay locking partitions during INSERT and UPDATE |
Previous Message | Robert Haas | 2019-02-01 13:51:55 | Re: Delay locking partitions during query execution |