Skip site navigation (1) Skip section navigation (2)

Re: Postgres scalability and performance on windows

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 (view raw or flat)
Thread:
Lists: pgsql-generalpgsql-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

In response to

pgsql-performance by date

Next:From: Peter ChildsDate: 2006-11-25 15:45:19
Subject: Massive delete of rows, how to proceed?
Previous:From: Bruce MomjianDate: 2006-11-24 23:43:36
Subject: Re: [HACKERS] [PERFORM] Direct I/O issues

pgsql-general by date

Next:From: sasan3@gmail.comDate: 2006-11-25 00:14:20
Subject: Re: PGDATA
Previous:From: Tom LaneDate: 2006-11-25 00:04:36
Subject: Re: more than one row returned by a subquery used as an expression

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group