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?
--
greg
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
