Re: speeding up planning with partitions
От | Amit Langote |
---|---|
Тема | Re: speeding up planning with partitions |
Дата | |
Msg-id | CA+HiwqE+hecJXroH0S1rhzRHmiYM1jEPqXqNb1Mh8G_d3LAP3g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: speeding up planning with partitions (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: speeding up planning with partitions
|
Список | pgsql-hackers |
On Sun, Mar 31, 2019 at 12:59 AM Robert Haas <robertmhaas@gmail.com> wrote: > > On Sat, Mar 30, 2019 at 11:46 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > > 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..." > > > > Ah. Grotty, but I guess it will cover the issue. > > I suppose it is. I am a little suspicious of the decision to make > PartitionPruneInfo structures depend on PartitionDesc indexes. Fwiw, I had complained when reviewing the run-time pruning patch that creating those maps in the planner and putting them in PartitionPruneInfo might not be a good idea, but David insisted that it'd be good for performance (in the context of using cached plans) to compute this information during planning. Thanks, Amit
В списке pgsql-hackers по дате отправления: