Re: ATTACH/DETACH PARTITION CONCURRENTLY
От | Robert Haas |
---|---|
Тема | Re: ATTACH/DETACH PARTITION CONCURRENTLY |
Дата | |
Msg-id | CA+TgmoZFq=U3X0+P=p-ETsBQQr5bevLgBGkFB2X78wtoLntX4A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: ATTACH/DETACH PARTITION CONCURRENTLY (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: ATTACH/DETACH PARTITION CONCURRENTLY
|
Список | pgsql-hackers |
On Thu, Nov 15, 2018 at 12:38 AM Michael Paquier <michael@paquier.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
В списке pgsql-hackers по дате отправления: