Chris Kratz <[EMAIL PROTECTED]> writes:

> We continue to tune our individual queries where we can, but it seems we 
> still 
> are waiting on the db a lot in our app.  When we run most queries, top shows 
> the postmaster running at 90%+ constantly during the duration of the request. 
> The disks get touched occasionally, but not often.  Our database on disk is 
> around 2.6G and most of the working set remains cached in memory, hence the 
> few disk accesses.  All this seems to point to the need for faster 
> processors.

I would suggest looking at the top few queries that are taking the most
cumulative time on the processor. It sounds like the queries are doing a ton
of logical i/o on data that's cached in RAM. A few indexes might cut down on
the memory bandwidth needed to churn through all that data.

> Items changed in the postgresql.conf:
> ...
> random_page_cost = 1          # units are one sequential page fetch cost

This makes it nigh impossible for the server from ever making a sequential
scan when an index would suffice. What query made you do this? What plan did
it fix?


---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?


Reply via email to