From: | tv(at)fuzzy(dot)cz |
---|---|
To: | sthomas(at)peak6(dot)com |
Cc: | "Adarsh Sharma" <adarsh(dot)sharma(at)orkash(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Re-Reason of Slowness of Query |
Date: | 2011-03-23 14:16:01 |
Message-ID: | 557a8c61e87e5e54ae205daadd8f0ca4.squirrel@sq.gransy.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
> On 03/23/2011 04:17 AM, Adarsh Sharma wrote:
>
>> explain analyze select distinct(p.crawled_page_id) from page_content
>> p where NOT EXISTS (select 1 from clause2 c where c.source_id =
>> p.crawled_page_id);
>
> You know... I'm surprised nobody has mentioned this, but DISTINCT is
> very slow unless you have a fairly recent version of Postgres that
> replaces it with something faster. Try this:
Nobody mentioned that because the explain plan already uses hash aggregate
(instead of the old sort)
HashAggregate (cost=100278.16..104104.75 rows=382659 width=8) (actual
time=7047.259..7050.261 rows=72 loops=1)
which means this is at least 8.4. Plus the 'distinct' step uses less than
1% of total time, so even if you improve it the impact will be minimal.
regards
Tomas
From | Date | Subject | |
---|---|---|---|
Next Message | Shaun Thomas | 2011-03-23 14:19:12 | Re: Re-Reason of Slowness of Query |
Previous Message | Uwe Bartels | 2011-03-23 13:39:55 | Re: buffercache/bgwriter |