Re: generic plans and "initial" pruning

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: generic plans and "initial" pruning
Дата
Msg-id 3633494.1659070517@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: generic plans and "initial" pruning  (Amit Langote <amitlangote09@gmail.com>)
Ответы Re: generic plans and "initial" pruning  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Amit Langote <amitlangote09@gmail.com> writes:
> On Thu, Jul 28, 2022 at 1:27 AM Robert Haas <robertmhaas@gmail.com> wrote:
>> 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.

> Tom may want to correct me but my understanding of why the planner
> waits till the end of planning to start populating the PlannerGlobal
> range table is that it is not until then that we know which subqueries
> will be scanned by the final plan tree, so also whose range table
> entries will be included in the range table passed to the executor.

It would not be profitable to flatten the range table before we've
done remove_useless_joins.  We'd end up with useless entries from
subqueries that ultimately aren't there.  We could perhaps do it
after we finish that phase, but I don't really see the point: it
wouldn't be better than what we do now, just the same work at a
different time.

            regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Smith
Дата:
Сообщение: Re: Functions 'is_publishable_class' and 'is_publishable_relation' should stay together.
Следующее
От: Kyotaro Horiguchi
Дата:
Сообщение: Re: standby recovery fails (tablespace related) (tentative patch and discussion)