Re: Properly pathify the union planner

Поиск
Список
Период
Сортировка
От Richard Guo
Тема Re: Properly pathify the union planner
Дата
Msg-id CAMbWs4_efcU0OxWtmJm8uECLoC=crT+Dwj98FiSXEw8tK10E4Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Properly pathify the union planner  (David Rowley <dgrowleyml@gmail.com>)
Ответы Re: Properly pathify the union planner  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers

On Wed, Mar 27, 2024 at 6:34 PM David Rowley <dgrowleyml@gmail.com> wrote:
On Wed, 27 Mar 2024 at 22:47, David Rowley <dgrowleyml@gmail.com> wrote:
> I did wonder when first working on this patch if subquery_planner()
> should grow an extra parameter, or maybe consolidate some existing
> ones by passing some struct that provides the planner with a bit more
> context about the query.  A few of the existing parameters are likely
> candidates for being in such a struct. e.g. hasRecursion and
> tuple_fraction. A SetOperationStmt could go in there too.

The attached is roughly what I had in mind.  I've not taken the time
to see what comments need to be updated, so the attached aims only to
assist discussion.

I like this idea.  And there may be future applications for having such
a struct if we want to pass down additional information to subquery
planning, such as ordering requirements from outer query.

Thanks
Richard

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

Предыдущее
От: Richard Guo
Дата:
Сообщение: Re: Remove some redundant set_cheapest() calls
Следующее
От: jian he
Дата:
Сообщение: Re: Add pg_basetype() function to obtain a DOMAIN base type