Re: Wrong rows estimations with joins of CTEs slows queries by more than factor 500
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Richard Guo <guofenglinux@gmail.com>
Cc: 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-17T19:42:00Z
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 →
-
Allow examine_simple_variable() to work on INSERT RETURNING Vars.
- 89b69db82adf 17.0 landed
-
Extract column statistics from CTE references, if possible.
- f7816aec23ee 17.0 landed
-
Remove SQL regression tests for GUCs related to NO_SHOW_ALL
- dbe8a1726cfd 15.3 cited
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