From: | Richard Guo <guofenglinux(at)gmail(dot)com> |
---|---|
To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
Cc: | Alexander Lakhin <exclusion(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Properly pathify the union planner |
Date: | 2024-03-28 02:48:03 |
Message-ID: | CAMbWs4_efcU0OxWtmJm8uECLoC=crT+Dwj98FiSXEw8tK10E4Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Mar 27, 2024 at 6:34 PM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> On Wed, 27 Mar 2024 at 22:47, David Rowley <dgrowleyml(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | jian he | 2024-03-28 02:54:08 | Re: Add pg_basetype() function to obtain a DOMAIN base type |
Previous Message | Richard Guo | 2024-03-28 02:27:10 | Re: Remove some redundant set_cheapest() calls |