Re: Incorrect cost for MergeAppend - Mailing list pgsql-hackers

From Alexander Kuzmenkov
Subject Re: Incorrect cost for MergeAppend
Date
Msg-id CALzhyqxQMDam+g7oV4nsQ88oZWpfXEXq7FN=ymxW83=wYErAhA@mail.gmail.com
Whole thread Raw
In response to Re: Incorrect cost for MergeAppend  (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>)
Responses Re: Incorrect cost for MergeAppend
List pgsql-hackers
I'd be happy to see this backpatched. What kind of regressions are we
worried about? I'd say partition-wise sort + merge should be faster
than append + sort for reasonably sized tables. That's basically what
tuplesort does inside. Moreso, this can enable index scans on
partitions, which is an even better plan.

On Wed, Jan 31, 2024 at 7:46 AM Ashutosh Bapat
<ashutosh.bapat.oss@gmail.com> wrote:
>
> On Wed, Jan 31, 2024 at 12:12 PM David Rowley <dgrowleyml@gmail.com> wrote:
> >
> > What is relevant are things like:
> >
> > For:
> > * It's a clear bug and what's happening now is clearly wrong.
> > * inheritance/partitioned table plan changes for the better in minor versions
> >
> > Against:
> > * Nobody has complained for 13 years, so maybe it's unlikely anyone is
> > suffering too much.
> > * Possibility of inheritance/partitioned table plans changing for the
> > worse in minor versions
> >
>
> That's what I am thinking as well. And the plans that may change for
> the worse are the ones where the costs with and without the patch are
> close.
>
> Just to be clear, the change is for good and should be committed to
> the master. It's the backpatching I am worried about.
>
> --
> Best Wishes,
> Ashutosh Bapat



pgsql-hackers by date:

Previous
From: Bharath Rupireddy
Date:
Subject: Re: Improve WALRead() to suck data directly from WAL buffers when possible
Next
From: "Hayato Kuroda (Fujitsu)"
Date:
Subject: RE: speed up a logical replica setup