Re: speeding up planning with partitions
От | Robert Haas |
---|---|
Тема | Re: speeding up planning with partitions |
Дата | |
Msg-id | CA+TgmoYkRYXHFReBjNbr1_wrNEJfS-UjNXwdeYnGx2EVG_QEOw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: speeding up planning with partitions (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: speeding up planning with partitions
|
Список | pgsql-hackers |
On Sat, Mar 30, 2019 at 11:11 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Before that, though, I remain concerned that the PartitionPruneInfo > data structure the planner is transmitting to the executor is unsafe > against concurrent ATTACH PARTITION operations. The comment for > PartitionedRelPruneInfo says in so many words that it's relying on > indexes in the table's PartitionDesc; how is that not broken by > 898e5e329? The only problem with PartitionPruneInfo structures of which I am aware is that they rely on PartitionDesc offsets not changing. But I added code in that commit in ExecCreatePartitionPruneState to handle that exact problem. See also paragraph 5 of the commit message, which begins with "Although in general..." -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: