On 20.8.2013 23:02, Tom Lane wrote: > Tomas Vondra <tv@xxxxxxxx> writes: > >> Anyway, I still don't understand why the same logic around >> hash_agg_entry_size should not apply to choose_hashed_grouping as >> well? Well, it would make it slower in this particular corner case, >> but wouldn't it be more correct? Meh, I meant it the other way around - applying the hashentrysize logic from hashed_grouping to hashed_distinct. So that both use 56B. > choose_hashed_grouping has it right, or at least more nearly right. > choose_hashed_distinct is simply failing to account for space that > will in fact be consumed. Not fixing that is not a good way to deal > with inaccurate number-of-groups estimates; if that estimate is low > rather than high, the consequences will be a lot worse than they are > here. Not quite sure how to parse this (not a native speaker here, sorry). Does that mean we want to keep it as it is now (because fixing it would cause even worse errors with low estimates)? Or do we want to fix hashed_distinct so that it behaves like hashed_grouping? Tomas -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
