From: | Tomas Vondra <tv(at)fuzzy(dot)cz> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: General performance/load issue |
Date: | 2011-11-27 00:28:16 |
Message-ID: | 4ED18420.3090803@fuzzy.cz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 26.11.2011 19:08, Tom Lane wrote:
> Tomas Vondra <tv(at)fuzzy(dot)cz> writes:
>> Anyway the output is a bit strange. It's writing a lot of temp files
>> that are significantly smaller (about 3MB) than work_mem (128MB).
>
> The most obvious guess about what's doing that is a hash join that has
> a drastic overestimate of how many rows it has to hash, so that it's
> batching the join unnecessarily. AFAIR, sorts don't spill to disk until
> they've actually reached work_mem, but hash join works differently.
OK, so it probably is not sorting, probably. What about other nodes
using hash table - aggregates etc.? Would those spill to the disk in
case of overestimation?
Gaetan did not post the whole query, but it starts like this:
SELECT COUNT(*) FROM (SELECT DISTINCT "table"."id" AS "id",
"table"."flux_id" AS "flux_id", "table"."locale_id" AS "locale_id",
...
so it obviously uses a DISTINCT clause, probably evaluated using a hash
aggregate. And this is allegedly one of the queries that write a lot.
Tomas
From | Date | Subject | |
---|---|---|---|
Next Message | Richard Greenwood | 2011-11-27 01:47:43 | text search synonym dictionary anomaly with numbers |
Previous Message | Adrian Klaver | 2011-11-26 20:33:35 | Re: How to add conversion between LATIN1 and WIN1251 ? |