Re: Incorrect cost for MergeAppend
David Rowley <dgrowleyml@gmail.com>
From: David Rowley <dgrowleyml@gmail.com>
To: Alexander Kuzmenkov <akuzmenkov@timescale.com>
Cc: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>,
pgsql-hackers@postgresql.org
Date: 2024-01-30T23:03:23Z
Lists: 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
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix costing bug in MergeAppend
- 9d1a5354f58c 17.0 landed
-
Fix locking when fixing an incomplete split of a GIN internal page
- 6a1ea02c491d 17.0 cited