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 CAMbWs4_rgwHYAGr=st8XFtdbcKHCf8ti7RpHxJfzv6iZ3AgxJA@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.  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Significant Execution Time Difference Between PG13.14 and PG16.4 for Query on information_schema Tables.
List pgsql-hackers
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.

> If we go forward with this, I'm thinking about
> changing add_nulling_relids' API contract to say "if target_relid
> is NULL then all level-zero Vars/PHVs are modified", so that we
> don't need that relid set in non-LATERAL cases.

+1.  In LATERAL case, we can always find the subquery's relids in
rcon->relids.  In non-lateral case, any level-zero Vars/PHVs must
belong to the subquery - so if we change add_nulling_relids' API to be
so, we do not need to have rcon->relids set.

Thanks
Richard



pgsql-hackers by date:

Previous
From: shveta malik
Date:
Subject: Re: Conflict detection and logging in logical replication
Next
From: Thomas Munro
Date:
Subject: Re: consider -Wmissing-variable-declarations