Message-ID: <5213EBE4.5030302@fuzzy.cz>
Date: Wed, 21 Aug 2013 00:21:24 +0200
From: Tomas Vondra <tv@fuzzy.cz>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: pgsql-performance@postgresql.org
Subject: Re: queries with DISTINCT / GROUP BY giving different plans
References: <3a56c4d2c0b2daa11a625c2983823901.squirrel@sq.gransy.com>
 <11586.1376505314@sss.pgh.pa.us> <520E7F33.7010305@fuzzy.cz>
 <7059.1377015896@sss.pgh.pa.us> <5213ADB1.3040807@fuzzy.cz>
 <13875.1377032529@sss.pgh.pa.us>
In-Reply-To: <13875.1377032529@sss.pgh.pa.us>
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

On 20.8.2013 23:02, Tom Lane wrote:
> Tomas Vondra <tv@fuzzy.cz> 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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance