Re: Back-patch change in hashed DISTINCT estimation?

On Wed, Aug 21, 2013 at 4:05 AM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> On 2013-08-20 17:24:18 -0400, Tom Lane wrote:
>> In a thread over in pgsql-performance, Tomas Vondra pointed out that
>> choose_hashed_distinct was sometimes making different choices than
>> choose_hashed_grouping, so that queries like these:
>>
>> select distinct x from ... ;
>> select x from ... group by 1;
>>
>> might get different plans even though they should be equivalent.
>> After some debugging it turns out that I omitted hash_agg_entry_size()
>> from the hash table size estimate in choose_hashed_distinct --- I'm pretty
>> sure I momentarily thought that this function must yield zero if there are
>> no aggregates, but that's wrong. So we need a patch like this:
>
>> What I'm wondering is whether to back-patch this or leave well enough
>> alone. The risk of back-patching is that it might destabilize plan
>> choices that people like. [...]
>
>> A possible compromise is to back-patch into 9.3 (where the argument about
>> destabilizing plan choices doesn't have much force yet), but not further.
>
> +1 for 9.3 only.

I agree. work_mem is hard to tune with any great precision
analytically. If it is carefully tuned, it was probably done
empirically, so changing the behavior in back branches seems bad.

Cheers,

Jeff