Re: Propagate pathkeys from CTEs up to the outer query - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Propagate pathkeys from CTEs up to the outer query
Date
Msg-id 2516483.1711388358@sss.pgh.pa.us
Whole thread Raw
In response to Propagate pathkeys from CTEs up to the outer query  (Richard Guo <guofenglinux@gmail.com>)
Responses Re: Propagate pathkeys from CTEs up to the outer query
List pgsql-hackers
Richard Guo <guofenglinux@gmail.com> writes:
> This patch was initially posted in that same thread and has received
> some comments from Tom in [2].  Due to the presence of multiple patches
> in that thread, it has led to confusion.  So fork a new thread here
> specifically dedicated to discussing the patch about exposing pathkeys
> from CTEs to the upper planner.

I got around to looking at this finally.  I was a bit surprised by
your choice of data structure.  You made a per-CTE-item cte_paths
list paralleling cte_plan_ids, but what I had had in mind was a
per-subplan list of paths paralleling glob->subplans and subroots.
This would mean that the code for ordinary SubqueryScans would
also need to fill in that list, but surely that's a trivial cost
compared to everything else we do to prepare a subplan.  I don't
think that we have any immediate need to remember that info for
an ordinary SubqueryScan, but it seems plausible that we will
in future.  Also, I'm not sure that a Path is fully interpretable
without the associated PlannerInfo (subroot), so keeping it
beside the list of subroots seems more future-proof than dissociating
it from that.  This approach would also be more amenable to postponing
creation of the subplans, as we speculated about earlier.  (I have
no near-term desire to actually do that, but maybe someday it will
happen.)

            regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Possibility to disable `ALTER SYSTEM`
Next
From: Tom Lane
Date:
Subject: Re: Possibility to disable `ALTER SYSTEM`