On Wed, 27 Mar 2024 at 06:20, Tom Lane wrote:
> That's not the fault of anything we did here; the IndexOnlyScan path
> in the subquery is in fact not marked with any pathkeys, even though
> clearly its result is sorted. I believe that's an intentional
> decision from way way back, that pathkeys
On Wed, Mar 27, 2024 at 1:20 AM Tom Lane wrote:
> Richard Guo writes:
> > I agree with your points. Previously I was thinking that CTEs were the
> > only scenario where we needed to remember the best path and only
> > required the best path's pathkeys. However, considering potential
> >
Richard Guo writes:
> I agree with your points. Previously I was thinking that CTEs were the
> only scenario where we needed to remember the best path and only
> required the best path's pathkeys. However, considering potential
> future use cases as you mentioned, I concur that having a
On Tue, Mar 26, 2024 at 1:39 AM Tom Lane wrote:
> 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
Richard Guo 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
On 29/1/2024 10:18, Richard Guo wrote:
In [1] we've reached a conclusion that for a MATERIALIZED CTE it's okay
to 'allow our statistics or guesses for the sub-query to subsequently
influence what the upper planner does'. Commit f7816aec23 exposes
column statistics to the upper planner. In the
In [1] we've reached a conclusion that for a MATERIALIZED CTE it's okay
to 'allow our statistics or guesses for the sub-query to subsequently
influence what the upper planner does'. Commit f7816aec23 exposes
column statistics to the upper planner. In the light of that, here is a
patch that
