Re: Retiring is_pushed_down - Mailing list pgsql-hackers

From Richard Guo
Subject Re: Retiring is_pushed_down
Date
Msg-id CAMbWs4-BGokURcVNDmEpQ8OG9Ur_2MP_+FVWRWb9OsC_DvX=4g@mail.gmail.com
Whole thread Raw
In response to Retiring is_pushed_down  (Richard Guo <guofenglinux@gmail.com>)
Responses Re: Retiring is_pushed_down
List pgsql-hackers

On Tue, Jul 25, 2023 at 3:39 PM Richard Guo <guofenglinux@gmail.com> wrote:
* This patch calculates the outer join relids that are being formed
generally in this way:

    bms_difference(joinrelids, bms_union(outerrelids, innerrelids))

Of course this can only be used after the outer join relids has been
added by add_outer_joins_to_relids().  This calculation is performed
multiple times during planning.  I'm not sure if this has performance
issues.  Maybe we can calculate it only once and store the result in
some place (such as in JoinPath)?

In the v2 patch, I added a member in JoinPath to store the relid set of
any outer joins that will be calculated at this join, and this would
avoid repeating this calculation when creating nestloop/merge/hash join
plan nodes.  Also fixed a comment in v2.

Thanks
Richard
Attachment

pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Performance degradation on concurrent COPY into a single relation in PG16.
Next
From: Peter Geoghegan
Date:
Subject: Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan