Re: Incorrect cost for MergeAppend

Поиск
Список
Период
Сортировка
От Alexander Kuzmenkov
Тема Re: Incorrect cost for MergeAppend
Дата
Msg-id CALzhyqxQMDam+g7oV4nsQ88oZWpfXEXq7FN=ymxW83=wYErAhA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Incorrect cost for MergeAppend  (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>)
Ответы Re: Incorrect cost for MergeAppend  (Alexander Kuzmenkov <akuzmenkov@timescale.com>)
Список 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 по дате отправления:

Предыдущее
От: Bharath Rupireddy
Дата:
Сообщение: Re: Improve WALRead() to suck data directly from WAL buffers when possible
Следующее
От: "Hayato Kuroda (Fujitsu)"
Дата:
Сообщение: RE: speed up a logical replica setup