From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Richard Guo <guofenglinux(at)gmail(dot)com>, 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 03:06:46 |
Message-ID: | CAApHDvqO-YREBHju31bF-_b77Zg4zwNe44UhzRGn1c+GVTTibQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, 28 Mar 2024 at 15:56, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I haven't studied the underlying problem yet, so I'm not quite
> buying into whether we need this struct at all ...
The problem is, when planning a UNION child query, we want to try and
produce some Paths that would suit the top-level UNION query so that a
Merge Append -> Unique can be used rather than a Append -> Sort ->
Unique or Append -> Hash Aggregate.
The problem is informing the UNION child query about what it is. I
thought I could do root->parent_root->parse->setOperations for a UNION
child to know what it is, but that breaks for a query such as:
WITH q1(x) AS (SELECT 1)
SELECT FROM q1 UNION SELECT FROM q1
as the CTE also has root->parent_root->parse->setOperations set and in
the above case, that's a problem as there's some code that tries to
match the non-resjunk child targetlists up with the SetOperationStmt's
SortGroupClauses, but there's a mismatch for the CTE. The actual
UNION children should have a 1:1 match for non-junk columns.
> but assuming
> we do, I feel like "PlannerContext" is a pretty poor name.
> There's basically nothing to distinguish it from "PlannerInfo",
> not to mention that readers would likely assume it's a memory
> context of some sort.
>
> Perhaps "SubqueryContext" or the like would be better? It
> still has the conflict with memory contexts though.
Maybe something with "Parameters" in the name?
David
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2024-03-28 03:06:57 | Re: Fix parallel vacuum buffer usage reporting |
Previous Message | Tom Lane | 2024-03-28 02:59:42 | Re: Add pg_basetype() function to obtain a DOMAIN base type |