On Wednesday 09 February 2005 03:59 pm, Greg Stark wrote:
> Chris Kratz <chris.kratz@vistashare.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.
Hmmm, yes we continue to use indexes judiciously. I actually think we've
overdone it in some cases since inserts are starting to slow in some critical
areas.
> > 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?
Yes, it got set back to 2. I was testing various settings suggested by a
posting in the archives and that one didn't get reset.
