On Wed, 27 Mar 2024 at 16:15, Richard Guo <guofengli...@gmail.com> wrote: > 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?
As far as I see, there's nothing to go on... well unless you counted canSetTag, which is false for the CTE (per analyzeCTE())... but that's certainly not the fix. 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 other CTE thread about the PathKey change you worked on highlights that something like this could be useful. I posted in [1] about this. David [1] https://postgr.es/m/CAApHDvrF53ErmonnpO77eDiJm7PyReZ+nD=4fsssomakx6+...@mail.gmail.com
