Heikki, Thanks for getting back to this! I really look forward to simplifying WAL tuning for users.
>>> min_recycle_wal_size >>> checkpoint_wal_size >>> >> <snip> >> >>> These settings are fairly intuitive for a DBA to tune. You begin by >>> figuring out how much disk space you can afford to spend on WAL, and set >>> checkpoint_wal_size to that (with some safety margin, of course). Then >>> you set checkpoint_timeout based on how long you're willing to wait for >>> recovery to finish. Finally, if you have infrequent batch jobs that need >>> a lot more WAL than the system otherwise needs, you can set >>> min_recycle_wal_size to keep enough WAL preallocated for the spikes. >> >> We'll want to rename them to make it even *more* intuitive. > > Sure, I'm all ears. My suggestion: max_wal_size min_wal_size ... these would be very easy to read & understand for users: "Set max_wal_size based on the amount of space you have available for the transaction log, or about 10% of the space available for your database if you don't have a specific allocation for the log. If your database involves large batch imports, you may want to increase min_wal_size to be at least the size of your largest batch." Suggested defaults: max_wal_size: 256MB min_wal_size: 64MB Please remind me because I'm having trouble finding this in the archives: how does wal_keep_segments interact with the new settings? >> But ... do I understand things correctly that checkpoint wouldn't "kick >> in" until you hit checkpoint_wal_size? If that's the case, isn't real >> disk space usage around 2X checkpoint_wal_size if spread checkpoint is >> set to 0.9? Or does checkpoint kick in sometime earlier? > > It kicks in earlier, so that the checkpoint *completes* just when > checkpoint_wal_size of WAL is used up. So the real disk usage is > checkpoint_wal_size. Awesome. This makes me very happy. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers