Re: Significant Execution Time Difference Between PG13.14 and PG16.4 for Query on information_schema Tables. - Mailing list pgsql-hackers

From Richard Guo
Subject Re: Significant Execution Time Difference Between PG13.14 and PG16.4 for Query on information_schema Tables.
Date
Msg-id CAMbWs49PDEbkb7_f=URpon+1tjUbi4Ewwhbf=6N=3XUURLZjWw@mail.gmail.com
Whole thread Raw
In response to Re: Significant Execution Time Difference Between PG13.14 and PG16.4 for Query on information_schema Tables.  (Richard Guo <guofenglinux@gmail.com>)
List pgsql-hackers
On Wed, Aug 28, 2024 at 11:30 AM Richard Guo <guofenglinux@gmail.com> wrote:
> On Wed, Aug 28, 2024 at 5:52 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > I realized that actually we do have the mechanism for making that
> > work: we could apply add_nulling_relids to the expression, if it
> > meets those same conditions.
>
> I think this should work, as long as we apply add_nulling_relids only
> to Vars/PHVs that belong to the subquery in this case, because only
> those Vars/PHVs would be nulled by the outer joins contained in the
> nullingrels.

To be more concrete, I know theoretically it is the whole expression
that is nullable by the outer joins, not its individual vars.  But in
this case if the contained vars (that belong to the subquery) become
NULL, the whole expression would be NULL too, because it does not
contain any non-strict constructs.  That's why I think this approach
should work.

Thanks
Richard



pgsql-hackers by date:

Previous
From: Bertrand Drouvot
Date:
Subject: Re: Flush pgstats file during checkpoints
Next
From: Tender Wang
Date:
Subject: Re: Eager aggregation, take 3