On 2/4/15 6:16 PM, David Steele wrote:
> On 2/4/15 3:06 PM, Robert Haas wrote:
>>> Hmmm, I see your point. I spend a lot of time on AWS and in
>>> container-world, where disk space is a lot more constrained. However,
>>> it probably makes more sense to recommend non-default settings for that
>>> environment, since it requires non-default settings anyway.
>>>
>>> So, 384MB?
>> That's certainly better, but I think we should go further. Again,
>> you're not committed to using this space all the time, and if you are
>> using it you must have a lot of write activity, which means you are
>> not running on a tin can and a string. If you have a little tiny
>> database, say 100MB, running on a little-tiny Amazon instance,
>> handling a small number of transactions, you're going to stay close to
>> wal_min_size anyway. Right?
>
> The main exception I can think of is when using dump/restore to upgrade
> instead of pg_upgrade. This would generate a lot of WAL for what could
> otherwise be a low-traffic database.
But you'd still want to use that extra WAL space so you're not
checkpointing every 3 seconds. Really I can't see this becoming an issue
unless you're about to run out of disk space.
Is there a defined way to find out how much space we have left on the
disk that's hosting WAL? If so we could curtail WAL size if we're close
to running out of room. (But, honestly, I think we should just set this
to 1-2GB and be done with it).
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com