The problem is that the HashAgg will have to maintain a counter for
every distinct value of trid, not just those that occur more than
once. So if there are a huge number of one-time-only values you could
still blow out memory (and HashAgg doesn't currently know how to spill
to disk).
One-tim
Hmm, if you do an enable_hashagg=false and then run the query (without
explain) does it work then?
pointspp=# set enable_hashagg = false;
SET
pointspp=# select trid, count(*) from pptran group by trid having
count(*) > 1;
ERROR: could not write block 661582 of temporary file: No space left
One question is what does the explain (without analyze) plan look like for
the above and are the row estimates valid in the case of one of the hash
plans.
pointspp=# explain select trid, count(*) from pptran group by trid
having count(*) > 1;
QUERY PLAN
--
0 means overcommit is enabled. You want to set it to something other
than 0 to prevent overcommitting and the consequent suprising process
deaths. Exactly what other values are accepted varies, but 0 isn't the
one for you.
I do not understand how 0 could mean overcommit is enabled. I do
Is there some reason you can't add more swap space?
Yes, disk space. I have about 2 GB of swap space enabled.
How do you know it is Postgres that is using lots of memory? The OOM killer
doesn't just kill of memory hogs, so you can't just assume the processes
being killed tells you which pr
Tom Lane wrote:
Patrick Rotsaert <[EMAIL PROTECTED]> writes:
on 31/01/2006 16:18 Tom Lane wrote :
http://www.postgresql.org/docs/8.1/static/kernel-resources.html#AEN18105
But /proc/sys/vm/overcommit_memory reads `0', so my gu
on 31/01/2006 16:18 Tom Lane wrote :
"Patrick Rotsaert" <[EMAIL PROTECTED]> writes:
At the time of the crash, the server logs:
LOG: server process (PID 21815) was terminated by signal 9
You're running on a Linux machine with memory overcommit e
The following bug has been logged online:
Bug reference: 2225
Logged by: Patrick Rotsaert
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.2
Operating system: Linux
Description:Backend crash -- BIG table
Details:
Situation:
-
Database with 1 table
