Horton

Re: Wrong rows estimations with joins of CTEs slows queries by more than factor 500

David G. Johnston <david.g.johnston@gmail.com>

View thread
From: "David G. Johnston" <david.g.johnston@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Richard Guo <guofenglinux@gmail.com>, Jian Guo <gjian@vmware.com>, Tomas Vondra <tomas.vondra@enterprisedb.com>, Hans Buschmann <buschmann@nidsa.net>, "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>, Zhenghua Lyu <zlyu@vmware.com>
Date: 2023-11-17T03:45:44Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Allow examine_simple_variable() to work on INSERT RETURNING Vars.

  2. Extract column statistics from CTE references, if possible.

  3. Remove SQL regression tests for GUCs related to NO_SHOW_ALL

On Thursday, November 16, 2023, Tom Lane <tgl@sss.pgh.pa.us> wrote:

>
> That line of argument also leads to the conclusion that it'd be
> okay to expose info about the ordering of the CTE result to the
> upper planner.  This patch doesn't do that, and I'm not sufficiently
> excited about the issue to go write some code.  But if someone else
> does, I think we shouldn't exclude doing it on the grounds of wanting
> to preserve an optimization fence.  The fence is sort of one-way
> in this line of thinking: information can propagate up to the outer
> planner level, but not down into the CTE plan.
>

This is indeed my understanding of what materialized means.  Basically, the
CTE is done first and in isolation; but any knowledge of its result shape
can be used when referencing it.

David J.