Re: Calculage avg. width when operator = is missing

On Wed, Sep 23, 2015 at 3:21 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> "Shulgin, Oleksandr" <oleksandr(dot)shulgin(at)zalando(dot)de> writes:
> > On Tue, Sep 22, 2015 at 11:56 PM, Alvaro Herrera <
> alvherre(at)2ndquadrant(dot)com>
> > wrote:
> >> 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?
>
> Certainly, eg it could affect a decision about whether to use a hash join
> or hash aggregation through changing the planner's estimate of the
> required hashtable size. We wouldn't be bothering to track that data if
> it didn't affect plans.
>
> Personally I think Alvaro's position is unduly conservative: to the extent
> that plans change it'd likely be for the better. But I'm not excited
> enough to fight hard about it.
>

Yeah, I can see now, as I was studying the hash node code today intensively
for an unrelated reason.

I also believe that given that we are going to have more accurate stats,
the plan changes in this case hopefully are a good thing.

--
Alex