pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Richard Guo <guofenglinux@gmail.com>
Cc: Jian Guo <gjian@vmware.com>
Cc: Tomas Vondra <tomas.vondra@enterprisedb.com>
Cc: Hans Buschmann <buschmann@nidsa.net>
Cc: pgsql-hackers@lists.postgresql.org <pgsql-hackers@lists.postgresql.org>
Cc: Zhenghua Lyu <zlyu@vmware.com>
Subject: Re: Wrong rows estimations with joins of CTEs slows queries by more than factor 500
Date: Fri, 17 Nov 2023 14:42:00 -0500
Message-ID: <754093.1700250120@sss.pgh.pa.us> (raw)
In-Reply-To: <CAMbWs49eVQMgfR-KNALJB15RR5r-zjNtNWnB0j5S=j40gtu1Jg@mail.gmail.com>
References: <4504e67078d648cdac3651b2960da6e7@nidsa.net>
	<SN6PR05MB5199BB4BB8C982BB519B6660C417A@SN6PR05MB5199.namprd05.prod.outlook.com>
	<46a7d950-7ca7-8ab9-76dd-f0bc7611c609@enterprisedb.com>
	<SN6PR05MB5199C0095508555B7D8D0D23C41EA@SN6PR05MB5199.namprd05.prod.outlook.com>
	<891440.1699483495@sss.pgh.pa.us>
	<CAMbWs4-W_81Q3ff1Bk3NU_ChRzOJK0njAoJanW-kXnPF0wjd1Q@mail.gmail.com>
	<414317.1700158568@sss.pgh.pa.us>
	<CAMbWs48Z_PvveOeankGA69=V=fqogusRKGVPBUGfYC0zDo1WPA@mail.gmail.com>
	<482957.1700192299@sss.pgh.pa.us>
	<CAMbWs49eVQMgfR-KNALJB15RR5r-zjNtNWnB0j5S=j40gtu1Jg@mail.gmail.com>

Richard Guo <guofenglinux@gmail.com> writes:
> On Fri, Nov 17, 2023 at 11:38 AM 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.

> Exactly!  Thanks for the detailed explanation.

OK.  I pushed the patch after a bit more review: we can simplify
things some more by using the subroot->parse querytree for all
tests.  After the previous refactoring, it wasn't buying us anything
to do some initial tests with the raw querytree.  (The original
idea of that, I believe, was to avoid doing find_base_rel if we
could; but now that's not helpful.)

			regards, tom lane





view thread (29+ messages)  latest in thread

Message-ID: <754093.1700250120@sss.pgh.pa.us>
Permalink:  ../754093.1700250120@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/754093.1700250120@sss.pgh.pa.us

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: tgl@sss.pgh.pa.us, guofenglinux@gmail.com, gjian@vmware.com, tomas.vondra@enterprisedb.com, buschmann@nidsa.net, pgsql-hackers@lists.postgresql.org, zlyu@vmware.com
  Subject: Re: Wrong rows estimations with joins of CTEs slows queries by more than factor 500
  In-Reply-To: <754093.1700250120@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox