tag:blogger.com,1999:blog-7615241590176793465.post4625458287479958517..comments2010-02-06T01:36:57.052+13:00François Marierhttp://www.blogger.com/profile/15799633745688818389noreply@blogger.comBlogger1125tag:blogger.com,1999:blog-7615241590176793465.post-32395023779784032652009-05-31T12:25:02.947+12:002009-05-31T12:25:02.947+12:00The <A HREF="http://wiki.postgresql.org/wiki/Performance_Optimization" REL="nofollow">PostgreSQL wiki</A> has an abundance of further information on this topic.<br /><br />As rule of thumb:<br /><br />If you're CPU-bound (backends consuming all available CPU) you need to reduce the complexity and/or amount of the queries hitting the database.<br /><br />If you're disk-bound (backends waiting for disk IO)<br /><br />on writes:<br /><br />Get a RAID-Controller with battery backed write cache<br /><br />on reads:<br /><br />You need to either increase your RAM to match the size of your working set or reduce the size of the working set.<br /><br />Most often people mix <A HREF="http://en.wikipedia.org/wiki/OLTP" REL="nofollow">OLTP</A> (live/fresh/regularly used) and <A HREF="http://en.wikipedia.org/wiki/Data_warehouse" REL="nofollow">DWH</A> (old/not regularly used/historical) data which causes the working set to grow indefinitely. Partitioning/Archiving historical data usually fixes these issues.Robehttp://www.blogger.com/profile/07283190347559096435noreply@blogger.com