public inbox for [email protected]
help / color / mirror / Atom feedFrom: David Rowley <[email protected]>
To: Alexander Lakhin <[email protected]>
Cc: MARK CALLAGHAN <[email protected]>
Cc: [email protected]
Cc: Andres Freund <[email protected]>
Subject: Re: benchmark results comparing versions 15.2 and 16
Date: Thu, 11 May 2023 10:27:28 +1200
Message-ID: <CAApHDvqeYkHJEkh0unC5OsJDDY9o2ZfwPFdQDFdqYxCYOXgLFw@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <CAFbpF8N4bVFZ+eyWFj_+fZXZFSayk2kJVtZnouUVKGHudiDrSw@mail.gmail.com>
<[email protected]>
<[email protected]>
On Thu, 11 May 2023 at 01:00, Alexander Lakhin <[email protected]> wrote:
> This time `git bisect` pointed at 3c6fc5820. Having compared execution plans
> (both attached), I see the following differences (3c6fc5820~1 vs 3c6fc5820):
Based on what you've sent, I'm uninspired to want to try to do
anything about it. The patched version finds a plan that's cheaper.
The row estimates are miles off with both plans. I'm not sure what
we're supposed to do here. It's pretty hard to make changes to the
planner's path generation without risking that a bad plan is chosen
when it wasn't beforehand with bad row estimates.
Is the new plan still slower if you increase work_mem so that the sort
no longer goes to disk? Maybe the planner would have picked Hash
Aggregate if the row estimates had been such that cost_tuplesort()
knew that the sort would have gone to disk.
David
view thread (8+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: benchmark results comparing versions 15.2 and 16
In-Reply-To: <CAApHDvqeYkHJEkh0unC5OsJDDY9o2ZfwPFdQDFdqYxCYOXgLFw@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox