| From: | "Shulgin, Oleksandr" <oleksandr(dot)shulgin(at)zalando(dot)de> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Calculage avg. width when operator = is missing |
| Date: | 2015-09-23 06:27:40 |
| Message-ID: | CACACo5QrzDAuWyr2YW7_wRRu-8+Kr-Nb8aKw_zs8T0qLLiwGpw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Sep 22, 2015 at 11:56 PM, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
wrote:
> Tom Lane wrote:
>
> > Should we consider this HEAD-only, or a back-patchable bug fix?
> > Or perhaps compromise on HEAD + 9.5?
>
> It looks like a bug to me, but I think it might destabilize approved
> execution plans(*), so it may not be such a great idea to back patch
> branches that are already released. I think HEAD + 9.5 is good.
>
> (*) I hear there are even applications where queries and their approved
> execution plans are kept in a manifest, and plans that deviate from that
> raise all kinds of alarms. I have never seen such a thing ...
>
Ugh. Anyway, do you expect any plans to change only due to avg. width
estimation being different? Why would that be so?
--
Alex
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Zhaomo Yang | 2015-09-23 07:11:46 | Re: CREATE POLICY and RETURNING |
| Previous Message | Shulgin, Oleksandr | 2015-09-23 06:24:10 | Re: Calculage avg. width when operator = is missing |