Hi, On Thu, 28 Jul 2005, Kari Lavikka wrote:
> ----------------->8 Relevant rows from postgresql.conf 8<----------------- > > shared_buffers = 15000 # min 16, at least max_connections*2, 8KB each > work_mem = 1536 # min 64, size in KB As an aside, I'd increase work_mem -- but it doesn't sound like that is your problem. > maintenance_work_mem = 32768 # min 1024, size in KB > > max_fsm_pages = 1000000 # min max_fsm_relations*16, 6 bytes each > max_fsm_relations = 5000 # min 100, ~50 bytes each > > vacuum_cost_delay = 15 # 0-1000 milliseconds > vacuum_cost_limit = 120 # 0-10000 credits > > bgwriter_percent = 2 # 0-100% of dirty buffers in each round > > fsync = true # turns forced synchronization on or off > # fsync, fdatasync, open_sync, or > open_datasync > wal_buffers = 128 # min 4, 8KB each Some benchmarking results out today suggest that wal_buffers = 1024 or even 2048 could greatly assist you. > commit_delay = 80000 # range 0-100000, in microseconds > commit_siblings = 10 # range 1-1000 This may explain the fact that you've got backed up queries and idle CPU -- I'm not certain though. What does disabling commit_delay do to your situation? Gavin ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly