Re: Calculage avg. width when operator = is missing - Mailing list pgsql-hackers

From Shulgin, Oleksandr
Subject Re: Calculage avg. width when operator = is missing
Date
Msg-id CACACo5QrHLS-0U1=t08Ex_Fj7Wkr8fEQznnoOqnHxZrROM09Ag@mail.gmail.com
Whole thread Raw
In response to Re: Calculage avg. width when operator = is missing  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Sep 23, 2015 at 3:21 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
"Shulgin, Oleksandr" <oleksandr.shulgin@zalando.de> writes:
> On Tue, Sep 22, 2015 at 11:56 PM, Alvaro Herrera <alvherre@2ndquadrant.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

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Rework the way multixact truncations work
Next
From: Simon Riggs
Date:
Subject: Re: a funnel by any other name