Re: General performance/load issue

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

In response to

Browse pgsql-general by date

  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 ?