Re: [PERFORM] [HACKERS] More benchmarking of wal_buffers
Christopher Kings-Lynne [EMAIL PROTECTED] writes: Here's a question then - what is the _drawback_ to having 1024 wal_buffers as opposed to 8? Waste of RAM? You'd be better off leaving that 8 meg available for use as general-purpose buffers ... What I mean is say you have an enterprise server doing heaps of transactions with lots of work. If you have scads of RAM, could you just shove up wal_buffers really high and assume it will improve performance? Chris ---(end of broadcast)--- TIP 3: 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
Re: [PERFORM] [HACKERS] More benchmarking of wal_buffers
Tom Lane wrote: Christopher Kings-Lynne [EMAIL PROTECTED] writes: I've just spent the last day and a half trying to benchmark our new database installation to find a good value for wal_buffers. The quick answer - there isn't, just leave it on the default of 8. I don't think this is based on a useful test for wal_buffers. The wal_buffers setting only has to be large enough for the maximum amount of WAL log data that your system emits between commits, because a commit (from anyone) is going to flush the WAL data to disk (for everyone). What happens when the only transaction running emits more WAL log data than wal_buffers can handle? A flush happens when the WAL buffers fill up (that's what I'd expect)? Didn't find much in the documentation about it... -- Kevin Brown [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PERFORM] [HACKERS] More benchmarking of wal_buffers
Kevin Brown [EMAIL PROTECTED] writes: What happens when the only transaction running emits more WAL log data than wal_buffers can handle? A flush happens when the WAL buffers fill up (that's what I'd expect)? Didn't find much in the documentation about it... A write, not a flush (ie, we don't force an fsync). Also, I think it writes only a few blocks, not all the available data. Don't recall the details on that. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PERFORM] [HACKERS] More benchmarking of wal_buffers
Christopher Kings-Lynne [EMAIL PROTECTED] writes: What I mean is say you have an enterprise server doing heaps of transactions with lots of work. If you have scads of RAM, could you just shove up wal_buffers really high and assume it will improve performance? There is no such thing as infinite RAM (or if there is, you paid *way* too much for your database server). My feeling is that it's a bad idea to put more than you absolutely have to into single-use buffers. Multi-purpose buffers are usually a better use of RAM. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
