On Mon, 2004-06-07 at 16:12, Dan Langille wrote: > On 7 Jun 2004 at 16:00, Rod Taylor wrote: > > > On Mon, 2004-06-07 at 15:45, Dan Langille wrote: > > > A production system has had a query recently degrade in performance. > > > What once took < 1s now takes over 1s. I have tracked down the > > > problem to a working example. > > > > What changes have you made to postgresql.conf? > > Nothing recently (ie. past few months). Nothing at all really. > Perhaps I need to start tuning that. > > > Could you send explain analyse again with SEQ_SCAN enabled but with > > nested loops disabled? > > See http://rafb.net/paste/results/zpJEvb28.html
This doesn't appear to be the same query as we were shown earlier. > > Off the cuff? I might hazard a guess that effective_cache is too low or > > random_page_cost is a touch too high. Probably the former. > > I grep'd postgresql.conf: > > #effective_cache_size = 1000 # typically 8KB each > #random_page_cost = 4 # units are one sequential page fetch cost This would be the issue. You haven't told PostgreSQL anything about your hardware. The defaults are somewhat modest. http://www.postgresql.org/docs/7.4/static/runtime-config.html Skim through the run-time configuration parameters that can be set in postgresql.conf. Pay particular attention to: * shared_buffers (you may be best with 2000 or 4000) * effective_cache_size (set to 50% of ram size if dedicated db machine) * random_page_cost (good disks will bring this down to a 2 from a 4) -- Rod Taylor <rbt [at] rbt [dot] ca> Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL PGP Key: http://www.rbt.ca/signature.asc ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
