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-27 03:14:52 |
Message-ID: | CAMbWs49gWbhSVdX0kT2x5XGKmP5OZerp6VhEA-hM4BvLHxKaqQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Mar 27, 2024 at 6:23 AM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> Because this field is set, it plans the CTE thinking it's a UNION
> child and breaks when it can't find a SortGroupClause for the CTE's
> target list item.
Right. The problem here is that we mistakenly think that the CTE query
is a subquery for the set operation and thus store the SetOperationStmt
in its qp_extra. Currently the code for the check is:
/*
* Check if we're a subquery for a set operation. If we are, store
* the SetOperationStmt in qp_extra.
*/
if (root->parent_root != NULL &&
root->parent_root->parse->setOperations != NULL &&
IsA(root->parent_root->parse->setOperations, SetOperationStmt))
qp_extra.setop =
(SetOperationStmt *) root->parent_root->parse->setOperations;
else
qp_extra.setop = NULL;
This check cannot tell if the subquery is for a set operation or a CTE,
because its parent might have setOperations set in both cases. Hmm, is
there any way to differentiate between the two?
Thanks
Richard
From | Date | Subject | |
---|---|---|---|
Next Message | shveta malik | 2024-03-27 03:31:50 | Re: Introduce XID age and inactive timeout based replication slot invalidation |
Previous Message | Nathan Bossart | 2024-03-27 02:40:50 | Re: recovery modules |