From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Erik Norvelle <signups(at)norvelle(dot)org> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Slow performance with Group By |
Date: | 2004-11-09 00:56:04 |
Message-ID: | 12781.1099961764@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Erik Norvelle <signups(at)norvelle(dot)org> writes:
>>> it=> explain select codelemm, sectref, count(codelemm) from indethom
> group by codelemm, sectref;
>>> QUERY PLAN
>>> -----------------------------------------------------------------------
> ---------
>>> GroupAggregate (cost=2339900.60..2444149.44 rows=1790528 width=13)
>>> -> Sort (cost=2339900.60..2364843.73 rows=9977252 width=13)
>>> Sort Key: codelemm, sectref
>>> -> Seq Scan on indethom (cost=0.00..455264.52 rows=9977252
> width=13)
Actually the painful part of that is the sort. If you bump up sort_mem
enough it will eventually switch over to a HashAggregate with no sort,
which may be a better plan if there's not too many groups (is the
estimate of 1.79 million on the mark at all??)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2004-11-09 01:31:22 | Re: Question regarding the file system |
Previous Message | John Meinel | 2004-11-09 00:31:33 | Re: vacuum analyze slows sql query |