Re: Incorrect cost for MergeAppend

Поиск
Список
Период
Сортировка
От David Rowley
Тема Re: Incorrect cost for MergeAppend
Дата
Msg-id CAApHDvo17CCW=fRKjCh3USwqgYWnJXjsNeWn67AqxtfUdFZeBg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Incorrect cost for MergeAppend  (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>)
Ответы Re: Incorrect cost for MergeAppend
Список pgsql-hackers
On Wed, 31 Jan 2024 at 18:58, Ashutosh Bapat
<ashutosh.bapat.oss@gmail.com> wrote:
> with patch
>  Merge Append  (cost=6.94..18.90 rows=198 width=4)

> without patch
>  Sort  (cost=19.04..19.54 rows=198 width=4)

> Those numbers are higher than 1% (#define STD_FUZZ_FACTOR 1.01) but
> slight variation in all the GUCs that affect cost, might bring the
> difference closer to STD_FUZZ_FACTOR.
>
> Given how close they are, maybe it's not such a good idea to
> backpatch.

The reason those numbers are close is because I reduced the row count
on the test tables to a point where we only just get the Merge Append
plan with a small margin.  I don't see the test case costs as a
relevant factor for if we backpatch or not.

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

For now, I'm on the fence on this one.

David



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Richard Guo
Дата:
Сообщение: Re: Oversight in reparameterize_path_by_child leading to executor crash
Следующее
От: Ashutosh Bapat
Дата:
Сообщение: Re: Incorrect cost for MergeAppend