From: | Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com> |
---|---|
To: | Richard Guo <guofenglinux(at)gmail(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Some revises in adding sorting path |
Date: | 2023-02-16 11:49:57 |
Message-ID: | CAPmGK16g=L5wguBbtPkQghkR-_L0L8DuYdT5iyJh94b07A+GOg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi Richard,
On Tue, Jan 10, 2023 at 8:06 PM Richard Guo <guofenglinux(at)gmail(dot)com> wrote:
> In add_paths_with_pathkeys_for_rel, we do not try incremental sort atop
> of the epq_path, which I think we can do. I'm not sure how useful this
> is in real world since the epq_path is used only for EPQ checks, but it
> seems doing that doesn't cost too much.
I'm not sure this is a good idea, because the epq_path will return at
most one tuple in an EPQ recheck.
The reason why an extra Sort node is injected into the epq_path is
only label it with the correct sort order to use it as an input for
the EPQ merge-join path of a higher-level foreign join, so shouldn't
we keep this step as much as simple and save cycles even a little?
Sorry for being late to the party.
Best regards,
Etsuro Fujita
From | Date | Subject | |
---|---|---|---|
Next Message | Drouvot, Bertrand | 2023-02-16 12:26:00 | Re: Change xl_hash_vacuum_one_page.ntuples from int to uint16 |
Previous Message | Jelte Fennema | 2023-02-16 11:49:38 | Re: proposal: psql: psql variable BACKEND_PID |