Re: Performance Tuning

Chris Kratz <chris(dot)kratz(at)vistashare(dot)com> 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?

--
greg