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

From: jian he <jian(dot)universality(at)gmail(dot)com>
To: Jian Guo <gjian(at)vmware(dot)com>
Cc: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Hans Buschmann <buschmann(at)nidsa(dot)net>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Wrong rows estimations with joins of CTEs slows queries by more than factor 500
Date: 2023-09-06 06:00:39
Message-ID: CACJufxGKASOPVyELxoZVX4vTOYZiQ53AfYYGm-nAcwrv4G-wsA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Aug 22, 2023 at 10:35 AM Jian Guo <gjian(at)vmware(dot)com> wrote:
>
> Sure, Tomas.
>
> Here is the PG Commitfest link: https://commitfest.postgresql.org/44/4510/
> ________________________________

hi.
wondering around http://cfbot.cputube.org/
there is a compiler warning: https://cirrus-ci.com/task/6052087599988736

I slightly edited the code, making the compiler warning out.

I am not sure if the following duplicate comment from (rte->rtekind ==
RTE_SUBQUERY && !rte->inh) branch is correct.
/*
* OK, recurse into the subquery. Note that the original setting
* of vardata->isunique (which will surely be false) is left
* unchanged in this situation. That's what we want, since even
* if the underlying column is unique, the subquery may have
* joined to other tables in a way that creates duplicates.
*/

Index varnoSaved = var->varno;
here varnoSaved should be int?

image attached is the coverage report
if I understand coverage report correctly,
`
if (rel->subroot) examine_simple_variable(rel->subroot, var, vardata);
`
the above never actually executed?

Attachment Content-Type Size
src_backend_utils_adt_selfuncs.c.gcov.html.png image/png 472.1 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message John Naylor 2023-09-06 06:23:43 Re: [PoC] Improve dead tuple storage for lazy vacuum
Previous Message Nishant Sharma 2023-09-06 05:55:35 Re: pg_basebackup: Always return valid temporary slot names