Re: Is select_outer_pathkeys_for_merge() too strict now we have Incremental Sorts?

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Richard Guo <guofenglinux(at)gmail(dot)com>
Cc: PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Is select_outer_pathkeys_for_merge() too strict now we have Incremental Sorts?
Date: 2022-07-20 19:46:46
Message-ID: CAApHDvpZQzC3rMNFi0UdLg7QhN6UHvRu4Shfd7wsqE2HiRg1jw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 20 Jul 2022 at 21:19, Richard Guo <guofenglinux(at)gmail(dot)com> wrote:
> So the idea is if the ECs used by the mergeclauses are prefix of the
> query_pathkeys, we use this prefix as pathkeys for the mergejoin. Why
> not relax this further that if the ECs in the mergeclauses and the
> query_pathkeys have common prefix, we use that prefix as pathkeys? So
> that we can have a plan like below:

I don't think that's a clear-cut win. There is scoring code in there
to try to arrange the pathkey list in the order of
most-useful-to-upper-level-joins firsts. If we were to do as you
describe we could end up generating worse plans when there is some
subsequent Merge Join above this one that has join conditions that the
query_pathkeys are not compatible with.

Maybe your idea could be made to work in cases where
bms_equal(joinrel->relids, root->all_baserels). In that case, we
should not be processing any further joins and don't need to consider
that as a factor for the scoring.

David

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2022-07-20 20:07:58 Re: System catalog documentation chapter
Previous Message Robert Haas 2022-07-20 19:11:09 Re: pg_auth_members.grantor is bunk