From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, Alvaro Herrera <alvherre(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: | 2018-11-15 13:57:31 |
Message-ID: | CA+TgmoZFq=U3X0+P=p-ETsBQQr5bevLgBGkFB2X78wtoLntX4A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Nov 15, 2018 at 12:38 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> On Thu, Nov 15, 2018 at 01:38:55PM +0900, Amit Langote wrote:
> > I've fixed 0001 again to re-order the code so that allocations happen the
> > correct context and now tests pass with the rebased patches.
>
> I have been looking at 0001, and it seems to me that you make even more
> messy the current situation. Coming to my point: do we have actually
> any need to set rel->rd_pdcxt and rel->rd_partdesc at all if a relation
> has no partitions? It seems to me that we had better set rd_pdcxt and
> rd_partdesc to NULL in this case.
I think that's unrelated to this patch, as Amit also says, but I have
to say that the last few hunks of the rebased version of this patch do
not make a lot of sense to me. This patch is supposed to be reducing
list construction, and the original version did that, but the rebased
version adds a partition_bounds_copy() operation, whereas my version
did not add any expensive operations - it only removed some cost. I
don't see why anything I changed should necessitate such a change, nor
does it seem like a good idea.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2018-11-15 14:10:17 | Re: [HACKERS] generated columns |
Previous Message | Andrey Borodin | 2018-11-15 12:30:25 | Re: Connections hang indefinitely while taking a gin index's LWLock buffer_content lock |