Re: Incorrect cost for MergeAppend
Alexander Kuzmenkov <akuzmenkov@timescale.com>
From: Alexander Kuzmenkov <akuzmenkov@timescale.com>
To: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
Cc: David Rowley <dgrowleyml@gmail.com>, pgsql-hackers@postgresql.org
Date: 2024-01-31T12:33:21Z
Lists: 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
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