On 02/04/2015 04: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.
Except that, when setting up servers for customers, one thing I pretty
much always do for them is temporarily increase checkpoint_segments for
the initial data load. So having Postgres do this automatically would
be a feature, not a bug.
I say we go with ~~ 1GB. That's an 8X increase over current default
size for the maximum
Default of 4 for min_wal_size?
On 02/04/2015 07:37 PM, Amit Kapila wrote:> On Thu, Feb 5, 2015 at 3:11
AM, Josh Berkus <josh@agliodbs.com
>> If we did add one, I'd suggest calling it "wal_size_limit" or something
>> similar.
>
> I think both the names (max_wal_size and wal_size_limit) seems to
> indicate the same same thing. Few more suggestions:
> typical_wal_size, wal_size_soft_limit?
Again, you're suggesting more complicated (and difficult to translate,
and for that matter misleading) names in order to work around a future
feature which nobody is currently working on, and we may never have.
Let's keep clear and simple parameter names which most people can
understand, instead of making things complicated for the sake of complexity.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
