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
|
Список | 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
a struct if we want to pass down additional information to subquery
planning, such as ordering requirements from outer query.
Thanks
Richard
В списке pgsql-hackers по дате отправления: