On Wednesday 09 February 2005 03:59 pm, Greg Stark wrote: > 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.
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. ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq