Re: generic plans and "initial" pruning
От | Robert Haas |
---|---|
Тема | Re: generic plans and "initial" pruning |
Дата | |
Msg-id | CA+TgmoZzmThMvz9HVqSTD1ESWbzn=KpWpag6SMsJQi+NbN3ghQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: generic plans and "initial" pruning (Amit Langote <amitlangote09@gmail.com>) |
Ответы |
Re: generic plans and "initial" pruning
|
Список | pgsql-hackers |
On Tue, Jul 26, 2022 at 11:01 PM Amit Langote <amitlangote09@gmail.com> wrote: > Needed to be rebased again, over 2d04277121f this time. 0001 adds es_part_prune_result but does not use it, so maybe the introduction of that field should be deferred until it's needed for something. I wonder whether it's really necessary to added the PartitionPruneInfo objects to a list in PlannerInfo first and then roll them up into PlannerGlobal later. I know we do that for range table entries, but I've never quite understood why we do it that way instead of creating a flat range table in PlannerGlobal from the start. And so by extension I wonder whether this table couldn't be flat from the start also. -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: