From: | "Mark Woodward" <pgsql(at)mohawksoft(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: PostgreSQL 8.0.6 crash |
Date: | 2006-02-09 16:14:28 |
Message-ID: | 16581.24.91.171.78.1139501668.squirrel@mail.mohawksoft.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> "Mark Woodward" <pgsql(at)mohawksoft(dot)com> writes:
>> -> HashAggregate (cost=106527.68..106528.68 rows=200
>> width=32)
>> Filter: (count(ucode) > 1)
>> -> Seq Scan on cdtitles (cost=0.00..96888.12
>> rows=1927912
>> width=32)
>
>> Well, shouldn't hash aggregate respect work memory limits?
>
> If the planner thought there were 1.7M distinct values, it wouldn't have
> used hash aggregate ... but it only thinks there are 200, which IIRC is
> the default assumption. Have you ANALYZEd this table lately?
I thought that I had, but I did CLUSTER at some point. Or maybe I didn't
I'm, not sure. I have been working on a file reader/parser/importer
program. I created and dropped the DB so many times it is hard to keep
track. Still, I would say that is is extremly bad behavior for not having
stats, wouldn't you think?
>
> Meanwhile, I'd strongly recommend turning off OOM kill. That's got to
> be the single worst design decision in the entire Linux kernel.
How is this any different than the FreeBSD having a default 512M process
size limit? On FreeBSD, the process would have been killed earlier.
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2006-02-09 16:17:48 | Re: PostgreSQL 8.0.6 crash |
Previous Message | Tom Lane | 2006-02-09 15:53:38 | Re: PostgreSQL 8.0.6 crash |