Re: [PERFORM] SSD + RAID

2009-12-03 Thread Scott Carey
On 11/19/09 1:04 PM, "Greg Smith" wrote: > That won't help. Once the checkpoint is done, the problem isn't just > that the WAL segments are recycled. The server isn't going to use them > even if they were there. The reason why you can erase/recycle them is > that you're doing so *after* writi

Re: [PERFORM] Checkpoint spikes

2009-12-03 Thread Greg Smith
Heikki Linnakangas wrote: I wonder how common this issue is? When we implemented spreading of the write phase, we had long discussions about spreading out the fsyncs too, but in the end it wasn't done. Perhaps it is time to revisit that now that 8.3 has been out for some time and people have expe

Re: [PERFORM] Checkpoint spikes

2009-12-03 Thread Heikki Linnakangas
Greg Smith wrote: > Richard Neill wrote: >> Here's the typical checkpoint logs: >> 2009-12-03 06:21:21 GMT LOG: checkpoint complete: wrote 12400 buffers >> (2.2%); 0 transaction log file(s) added, 0 removed, 12 recycled; >> write=149.883 s, sync=5.143 s, total=155.040 s > See that "sync" number th

Re: [PERFORM] Analyse without locking?

2009-12-03 Thread Laurent Laborde
On Sat, Nov 28, 2009 at 6:57 PM, Richard Neill wrote: > Greg Smith wrote: >> >> Richard Neill wrote: >>> >>> Or am I barking up the wrong tree entirely? >> >> If you haven't already tuned checkpoint behavior, it's more likely that's >> causing a dropout than autovacuum.  See the checkpoint_segment

[PERFORM] Re: [BUGS] BUG #5228: Execution of prepared query is slow when timestamp parameter is used

2009-12-03 Thread Craig Ringer
aftab wrote: > The following bug has been logged online: > > Bug reference: 5228 > Logged by: aftab > Email address: akha...@hotmail.co.uk > PostgreSQL version: 8.3.8 > Operating system: Centos 5 > Description:Execution of prepared query is slow when timestamp > parame