Quoting Stephane Tessier [EMAIL PROTECTED]:
General parameter suggestions:
shared_buffers = 128000 # min max_connections*2 or 16, 8KB each
effective_cache_size = 196608 # typically 8KB each
Try reducing shared_buffers (say 3). There has been much discussion regards
setting this
A furthur thought or two:
- you are *sure* that it is Postgres that is slow? (could be Php...or your
machine could be out of some resource - see next 2 points)
- is your machine running out of cpu or memory?
- is your machine seeing huge io transfers or long io waits?
- are you running Php on
It may be worth pricing up expansion options e.g. 256M or more.
The other path to consider is changing RAID5 - RAID10 if your card supports it.
However, I would recommend reducing that shared_buffers setting and doing your
performance measurements *again* - before changing anything else. This is
Hi Mischa,
You probably need to determine whether the bottleneck is cpu or disk (should be
easy enough!)
Having said that, assuming your application is insert/update intensive I would
recommend:
- mount the ufs filesystems Pg uses *without* logging
- use postgresql.conf setting
Quoting Harry Hehl [EMAIL PROTECTED]:
Mark,
(snippage)However I am still getting seq scans on indexes for other queries
For example:
select * from omfile where ( objectid in ( select distinct(ref_oid)
from
ts ) );
objectid ref_oid are non-unique indexes
omimagefile omclipfile
Quoting [EMAIL PROTECTED] [EMAIL PROTECTED]:
Hmm - that first query needs to do a sort, so you might want to
experiment with
the sort_mem parameter
Oops - I mean work_mem...
---(end of broadcast)---
TIP 5: don't forget to increase your free
