Re: Out of memory error during large hashagg

On Mon, 2006-09-18 at 14:08 -0700, Casey Duncan wrote:
> I've reported variants of this in the past, but this case is entirely
> repeatable.
>
> Executing this query:
>
> select st_id, min(seed_id) as "initial_seed_id", count(*) as
> "seed_count"
> from seed group by st_id;
>
> The query plan and table stats are:
>
>                                QUERY PLAN
> -----------------------------------------------------------------------
> HashAggregate  (cost=1362694.83..1365164.68 rows=164656 width=16)
>     ->  Seq Scan on seed  (cost=0.00..964065.62 rows=53150562 width=16)
>
>
>   relname | relpages |  reltuples
> ---------+----------+-------------
> seed    |   428880 | 5.26984e+07
>

The hashagg doesn't yet have scroll to disk capability, so a bad
estimation of ndistinct will cause this to fail (at any release). This
is a known issue for certain distributions of data only. The workaround
is the one you know about already: enable_hashagg = off

I'm interested in collecting info on the distribution of data.
Can you post:

select tablename, attname, n_distinct from pg_stats
where attname = 'st_id';

select count(distinct st_id) from seed;

and also the table definition, including the PK

--
  Simon Riggs
  EnterpriseDB   http://www.enterprisedb.com