From: | Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> |
---|---|
To: | Kevin Bartz <kbartz(at)loyaltymatrix(dot)com> |
Cc: | 'Lincoln Yeoh' <lyeoh(at)pop(dot)jaring(dot)my>, 'Manfred Koizar' <mkoi-pg(at)aon(dot)at>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Out of swap space & memory |
Date: | 2004-08-09 19:12:23 |
Message-ID: | 20040809191223.GB7939@dcc.uchile.cl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Mon, Aug 09, 2004 at 11:33:04AM -0700, Kevin Bartz wrote:
> Hi Lincoln! Thanks for your reply. On the problematic SELECT INTO, EXPLAIN
> says:
>
> test=#
> QUERY PLAN
> ------------------------------------------------------------------
> HashAggregate (cost=42.50..42.50 rows=1000 width=356)
> -> Seq Scan on hp_raw (cost=0.00..20.00 rows=1000 width=356)
> (2 rows)
Maybe a hash aggregate is not a good idea in this case. Try applying
ANALYZE to the table before the SELECT INTO, and EXPLAIN again. Or
execute "SET enable_hashagg TO off" before the SELECT INTO.
Food for thought: do we need to make the HashAggregate code able to save
to disk if the space estimate turns out to be wrong?
--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Uno combate cuando es necesario... ¡no cuando está de humor!
El humor es para el ganado, o para hacer el amor, o para tocar el
baliset. No para combatir." (Gurney Halleck)
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-08-09 19:31:00 | Re: Losing records when server hang |
Previous Message | Scott Marlowe | 2004-08-09 18:47:01 | Re: Losing records when server hang |