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 по дате отправления: