From: | "Daniel Westermann (DWE)" <daniel(dot)westermann(at)dbi-services(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Alexander Kuzmenkov <akuzmenkov(at)timescale(dot)com> |
Cc: | Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, David Rowley <dgrowleyml(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Incorrect cost for MergeAppend |
Date: | 2024-01-31 14:24:44 |
Message-ID: | GV0P278MB04190DA12A364217AA4F99BCD27C2@GV0P278MB0419.CHEP278.PROD.OUTLOOK.COM |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Fabrízio de Royes Mello | 2024-01-31 14:25:06 | Re: speed up a logical replica setup |
Previous Message | James Coleman | 2024-01-31 13:53:39 | Re: Parallelize correlated subqueries that execute within each worker |