Re: Incorrect cost for MergeAppend
Daniel Westermann (DWE) <daniel.westermann@dbi-services.com>
From: "Daniel Westermann (DWE)" <daniel.westermann@dbi-services.com>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>, Alexander Kuzmenkov <akuzmenkov@timescale.com>
Cc: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>, David Rowley <dgrowleyml@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2024-01-31T14:24:44Z
Lists: pgsql-hackers
Hi, >Since we have a minor coming up very soon, I think it's not a good idea >to backpatch right now. Maybe you can push to master now, and consider >whether to backpatch later. >The problem is -- if somebody has an application that gets good plans >with the current cost model, and you change the cost model and the plans >become worse, what do they do? If you change this in a major release, >this is not an issue because they must test their queries before >upgrading and if they fail to realize a problem exists then it's their >fault. If you change it in a minor release, then those people will be >very upset that things were changed suddenly, and they may get wary of >future minor upgrades, which we don't want. I agree with this, especially as we tell our customers that such changes do not happen from one minor release to another. Regards Daniel
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