On Thu, 28 Mar 2024 at 15:56, Tom Lane <t...@sss.pgh.pa.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