Re: Redesigning checkpoint_segments
От | Josh Berkus |
---|---|
Тема | Re: Redesigning checkpoint_segments |
Дата | |
Msg-id | 54D2920A.60605@agliodbs.com обсуждение исходный текст |
Ответ на | Redesigning checkpoint_segments (Heikki Linnakangas <hlinnakangas@vmware.com>) |
Ответы |
Re: Redesigning checkpoint_segments
Re: Redesigning checkpoint_segments Re: Redesigning checkpoint_segments |
Список | pgsql-hackers |
On 02/04/2015 12:06 PM, Robert Haas wrote: > On Wed, Feb 4, 2015 at 1:05 PM, Josh Berkus <josh@agliodbs.com> wrote: >> Let me push "max_wal_size" and "min_wal_size" again as our new parameter >> names, because: >> >> * does what it says on the tin >> * new user friendly >> * encourages people to express it in MB, not segments >> * very different from the old name, so people will know it works differently > > That's not bad. If we added a hard WAL limit in a future release, how > would that fit into this naming scheme? Well, first, nobody's at present proposing a patch to add a hard limit, so I'm reluctant to choose non-obvious names to avoid conflict with a feature nobody may ever write. There's a number of reasons a hard limit would be difficult and/or undesirable. If we did add one, I'd suggest calling it "wal_size_limit" or something similar. However, we're most likely to only implement the limit for archives, which means that it might acually be called "archive_buffer_limit" or something more to the point. > 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? Well, we can test that. So what's your proposed size? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
В списке pgsql-hackers по дате отправления: