Re: Incorrect cost for MergeAppend

Поиск
Список
Период
Сортировка
От David Rowley
Тема Re: Incorrect cost for MergeAppend
Дата
Msg-id CAApHDvoNzHeMgfwPDSesJ7Tp2TzVxWS+AHAMtWrSr==HzsACmQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Incorrect cost for MergeAppend  (Alexander Kuzmenkov <akuzmenkov@timescale.com>)
Ответы Re: Incorrect cost for MergeAppend
Список pgsql-hackers
On Wed, 31 Jan 2024 at 02:23, Alexander Kuzmenkov
<akuzmenkov@timescale.com> wrote:
>
> On Tue, Jan 30, 2024 at 1:20 PM David Rowley <dgrowleyml@gmail.com> wrote:
> > You should likely focus on trying to find a test that does not require
> > making 2 tables with 10k rows.
>
> Is 1k smallint OK? It should fit in one page. Still reproduces the
> error, and the entire test case runs in under 10 ms.

I had a go at making it a bit smaller without going dangerously close
to where the plan might change. The following seems to work.

create table ma0(a int primary key);
create table ma1() inherits (ma0);
insert into ma0 select generate_series(1, 400);
insert into ma1 select generate_series(1, 200);
analyze ma0;
analyze ma1;

explain (costs off) select * from ma0 where a < 100 order by a;

drop table ma0 cascade;

As for backpatching this.  It does risk plans changing in stable
versions of PostgreSQL, which we normally try to avoid.  However, it
seems quite similar to 1e731ed12a, albeit, far more long-standing.
I'm currently thinking we should backpatch this back to 12.

Does anyone disagree?

David



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

Предыдущее
От: Dave Cramer
Дата:
Сообщение: Re: [PATCH] Add native windows on arm64 support
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: why there is not VACUUM FULL CONCURRENTLY?