From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | Magnus Hagander <magnus(at)hagander(dot)net>, Greg Smith <greg(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: auto-sizing wal_buffers |
Date: | 2011-01-13 23:06:24 |
Message-ID: | AANLkTi=No26FrfqaNbB49JkYTUmsqnwteAkYGxaaENn4@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jan 13, 2011 at 6:02 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
>
>> Depends what people want to do. We could make the default "0kB", and
>> define that to mean "auto-tune", or we could remove the parameter
>> altogether. I think I was envisioning the latter, but if people are
>> hesitant to do that we could do the former instead.
>
> Unfortunately, we might still need a manual parameter for override
> because of the interaction between wal_buffers and
> synchronous_commit=off, since it sets the max size of the unflushed data
> buffer. Discuss?
Do we have any evidence there's actually a problem in that case, or
that a larger value of wal_buffers solves it? I mean, the background
writer is going to start a background flush as quickly as it can...
> And the "auto" setting should be -1, not 0kB. We use -1 for "use
> default" for several other GUCs.
No can do. Gotta have things in the same units.
> Other than that, I think Greg's numbers are fine, and strongly support
> having one less thing to tune.
OK.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Joel Jacobson | 2011-01-13 23:10:17 | Do magic using pg_depend |
Previous Message | Josh Berkus | 2011-01-13 23:02:12 | Re: auto-sizing wal_buffers |