Re: Incorrect cost for MergeAppend
| От | Daniel Westermann (DWE) |
|---|---|
| Тема | Re: Incorrect cost for MergeAppend |
| Дата | |
| Msg-id | GV0P278MB04190DA12A364217AA4F99BCD27C2@GV0P278MB0419.CHEP278.PROD.OUTLOOK.COM обсуждение исходный текст |
| Ответ на | Re: Incorrect cost for MergeAppend (Alvaro Herrera <alvherre@alvh.no-ip.org>) |
| Список | 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.
>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
В списке pgsql-hackers по дате отправления: