From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Gopal" <gopal(at)getmapping(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Postgres scalability and performance on windows |
Date: | 2006-11-25 00:10:05 |
Message-ID: | 1164.1164413405@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-performance |
"Gopal" <gopal(at)getmapping(dot)com> writes:
> Thanks for your suggestions. Here's an output of the explain analyse.
What's the query exactly, and what are the schemas of the tables it
uses (psql \d descriptions would do)?
The actual runtime seems to be almost all spent in the hash aggregation
step:
> -> HashAggregate (cost=58.13..58.16 rows=1 width=117) (actual time=15.572..15.573 rows=2 loops=1)
> -> Hash IN Join (cost=3.34..58.10 rows=7 width=117) (actual time=0.261..0.544 rows=50 loops=1)
15 msec seems like a long time to aggregate only 50 rows, so I'm
wondering what aggregates are being calculated and over what
datatypes...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | sasan3@gmail.com | 2006-11-25 00:14:20 | Re: PGDATA |
Previous Message | Tom Lane | 2006-11-25 00:04:36 | Re: more than one row returned by a subquery used as an expression |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Childs | 2006-11-25 15:45:19 | Massive delete of rows, how to proceed? |
Previous Message | Bruce Momjian | 2006-11-24 23:43:36 | Re: [HACKERS] [PERFORM] Direct I/O issues |