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 →
  1. Fix costing bug in MergeAppend

  2. Fix locking when fixing an incomplete split of a GIN internal page