proposal: Set effective_cache_size to greater of .conf value, shared_buffers
Reference: http://postgresql.1045698.n5.nabble.com/Simple-join-doesn-t-use-index-td5738689.html
This is a pretty common gotcha: user sets shared_buffers but misses
the esoteric but important effective_cache_size. ISTM
effective_cache_size should always be >= shared buffers -- this is a
soft configuration error that could be reported as a warning and
perhaps overridden on the fly.
merlin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Jan 8, 2013 at 11:39 AM, Merlin Moncure <mmoncure@gmail.com> wrote:
Reference: http://postgresql.1045698.n5.nabble.com/Simple-join-doesn-t-use-index-td5738689.html
This is a pretty common gotcha: user sets shared_buffers but misses
the esoteric but important effective_cache_size. ISTM
effective_cache_size should always be >= shared buffers -- this is a
soft configuration error that could be reported as a warning and
perhaps overridden on the fly.
Not true. If there are many concurrent users running concurrent
queries against parallel databases, such as some test systems I have
that contain many databases for many test environments, such a setting
wouldn't make sense. If a DBA sets it to lower than shared_buffers,
that setting has to be honored.
Rather, I'd propose the default setting should be "-1" or something
"default" and "automagic" that works most of the time (but not all).
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Jan 8, 2013 at 9:53 AM, Claudio Freire <klaussfreire@gmail.com> wrote:
On Tue, Jan 8, 2013 at 11:39 AM, Merlin Moncure <mmoncure@gmail.com> wrote:
Reference: http://postgresql.1045698.n5.nabble.com/Simple-join-doesn-t-use-index-td5738689.html
This is a pretty common gotcha: user sets shared_buffers but misses
the esoteric but important effective_cache_size. ISTM
effective_cache_size should always be >= shared buffers -- this is a
soft configuration error that could be reported as a warning and
perhaps overridden on the fly.Not true. If there are many concurrent users running concurrent
queries against parallel databases, such as some test systems I have
that contain many databases for many test environments, such a setting
wouldn't make sense. If a DBA sets it to lower than shared_buffers,
that setting has to be honored.Rather, I'd propose the default setting should be "-1" or something
"default" and "automagic" that works most of the time (but not all).
+1. I've found that a value of three-quarters of system memory works
pretty well most of the time. Of course, there's not a single,
portable way of getting that on every platform we support. If I
remember my last investigation into this area, to use that particular
rule we would probably need at least three paths - one for Windows,
one for System V descendents, and one for BSD descendents. And there
might still be obscure things that wouldn't be covered. Of course
this also makes the admittedly unwarranted assumption that the
database owns the box, which could be wrong too, but purposely
lowballing effective_cache_size to discourage index-scan plans seems
unlikely to be a winning strategy.
A cruder heuristic that might be useful is 3 * shared_buffers. If
people follow the guidance to set shared_buffers around 25% of RAM,
then this will work out to around 75% again. Of course, many people,
for valid reasons, use smaller values of shared_buffers than that, and
a few use larger ones. It might still be better than no auto-tuning,
though I wouldn't swear to it.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Jan 8, 2013 at 05:23:36PM -0500, Robert Haas wrote:
Rather, I'd propose the default setting should be "-1" or something
"default" and "automagic" that works most of the time (but not all).+1. I've found that a value of three-quarters of system memory works
pretty well most of the time. Of course, there's not a single,
portable way of getting that on every platform we support. If I
remember my last investigation into this area, to use that particular
rule we would probably need at least three paths - one for Windows,
one for System V descendents, and one for BSD descendents. And there
might still be obscure things that wouldn't be covered. Of course
this also makes the admittedly unwarranted assumption that the
database owns the box, which could be wrong too, but purposely
lowballing effective_cache_size to discourage index-scan plans seems
unlikely to be a winning strategy.A cruder heuristic that might be useful is 3 * shared_buffers. If
people follow the guidance to set shared_buffers around 25% of RAM,
then this will work out to around 75% again. Of course, many people,
for valid reasons, use smaller values of shared_buffers than that, and
a few use larger ones. It might still be better than no auto-tuning,
though I wouldn't swear to it.
Agreed. This is similar to the fudge we have about random_page_cost:
Random access to mechanical disk storage is normally much more expensive
than four-times sequential access. However, a lower default is used
(4.0) because the majority of random accesses to disk, such as indexed
reads, are assumed to be in cache. The default value can be thought of
as modeling random access as 40 times slower than sequential, while
expecting 90% of random reads to be cached.
effective_cache_size is impossible to set accurately because you have no
idea what other things might be in the cache, or what other concurrent
queries might be filling the cache. Going with something at least
partly reasonable makes a lot more sense. While we don't know the size
of RAM, we do know the size of shared_buffers, and keying on that for a
default seems like a no-brainer, rather than using 128MB.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
On Tue, Jan 8, 2013 at 9:53 AM, Claudio Freire <klaussfreire@gmail.com> wrote:
Rather, I'd propose the default setting should be "-1" or something
"default" and "automagic" that works most of the time (but not all).
A cruder heuristic that might be useful is 3 * shared_buffers.
Both parts of that work for me. It's certainly silly that the default
value of effective_cache_size is now equivalent to the default value
of shared_buffers. And I don't especially like the idea of trying to
make it depend directly on the box's physical RAM, for the same
practical reasons Robert mentioned.
It might be better to use 4 * shared_buffers, as that corresponds to the
multiple that's been the default since 8.2 or so (ie 128MB vs 32MB), and
3x just seems kinda oddball.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Jan 8, 2013 at 7:17 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Robert Haas <robertmhaas@gmail.com> writes:
On Tue, Jan 8, 2013 at 9:53 AM, Claudio Freire <klaussfreire@gmail.com> wrote:
Rather, I'd propose the default setting should be "-1" or something
"default" and "automagic" that works most of the time (but not all).A cruder heuristic that might be useful is 3 * shared_buffers.
Both parts of that work for me. It's certainly silly that the default
value of effective_cache_size is now equivalent to the default value
of shared_buffers. And I don't especially like the idea of trying to
make it depend directly on the box's physical RAM, for the same
practical reasons Robert mentioned.
For the record, I don't believe those problems would be particularly
hard to solve.
It might be better to use 4 * shared_buffers, as that corresponds to the
multiple that's been the default since 8.2 or so (ie 128MB vs 32MB), and
3x just seems kinda oddball.
I suspect that would be OK, too.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
On Tue, Jan 8, 2013 at 7:17 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
... And I don't especially like the idea of trying to
make it depend directly on the box's physical RAM, for the same
practical reasons Robert mentioned.
For the record, I don't believe those problems would be particularly
hard to solve.
Well, the problem of "find out the box's physical RAM" is doubtless
solvable if we're willing to put enough sweat and tears into it, but
I'm dubious that it's worth the trouble. The harder part is how to know
if the box is supposed to be dedicated to the database. Bear in mind
that the starting point of this debate was the idea that we're talking
about an inexperienced DBA who doesn't know about any configuration knob
we might provide for the purpose.
I'd prefer to go with a default that's predictable and not totally
foolish --- and some multiple of shared_buffers seems like it'd fit the
bill.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 01/08/2013 08:08 PM, Tom Lane wrote:
Robert Haas <robertmhaas@gmail.com> writes:
On Tue, Jan 8, 2013 at 7:17 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
... And I don't especially like the idea of trying to
make it depend directly on the box's physical RAM, for the same
practical reasons Robert mentioned.For the record, I don't believe those problems would be particularly
hard to solve.Well, the problem of "find out the box's physical RAM" is doubtless
solvable if we're willing to put enough sweat and tears into it, but
I'm dubious that it's worth the trouble. The harder part is how to know
if the box is supposed to be dedicated to the database. Bear in mind
that the starting point of this debate was the idea that we're talking
about an inexperienced DBA who doesn't know about any configuration knob
we might provide for the purpose.I'd prefer to go with a default that's predictable and not totally
foolish --- and some multiple of shared_buffers seems like it'd fit the
bill.
+1. That seems to be by far the biggest bang for the buck. Anything else
will surely involve a lot more code for not much more benefit.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
All,
Well, the problem of "find out the box's physical RAM" is doubtless
solvable if we're willing to put enough sweat and tears into it, but
I'm dubious that it's worth the trouble. The harder part is how to know
if the box is supposed to be dedicated to the database. Bear in mind
that the starting point of this debate was the idea that we're talking
about an inexperienced DBA who doesn't know about any configuration knob
we might provide for the purpose.
Frankly, you'd need to go through a whole decision tree to do this right:
- How much RAM do you have?
- Is that RAM shared with other services?
- Is this a DW or OLTP server?
... etc.
We just don't want to get into that in the core code. However ...
I'd prefer to go with a default that's predictable and not totally
foolish --- and some multiple of shared_buffers seems like it'd fit the
bill.+1. That seems to be by far the biggest bang for the buck. Anything else
will surely involve a lot more code for not much more benefit.
I don't think we're going far enough here. I think there should be an
optional setting in postgresql.conf called:
available_ram
The, shared_buffers, wal_buffers, and effective_cache_size (and possible
other future settings) can be set to -1. If they are set to -1, then we
use the figure:
shared_buffers = available_ram * 0.25
(with a ceiling of 8GB)
wal_buffers = available_ram * 0.05
(with a ceiling of 32MB)
effective_cache_size = available_ram * 0.75
(with a floor of 128MB)
If they are set to an amount, then we use the amount they are set to.
It would be nice to also automatically set work_mem, maint_work_mem,
temp_buffers, etc. based on the above, but that would be considerably
more difficult and require performance testing we haven't done yet.
--
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
On Wed, Jan 9, 2013 at 2:01 AM, Josh Berkus <josh@agliodbs.com> wrote:
All,
Well, the problem of "find out the box's physical RAM" is doubtless
solvable if we're willing to put enough sweat and tears into it, but
I'm dubious that it's worth the trouble. The harder part is how to know
if the box is supposed to be dedicated to the database. Bear in mind
that the starting point of this debate was the idea that we're talking
about an inexperienced DBA who doesn't know about any configuration knob
we might provide for the purpose.For what it is worth even if it is a dedicated database box 75% might be
way too high. I remember investigating bad performance on our biggest
database server, that in the end turned out to be a too high setting of
effective_cache_size. From reading the code back then my rationale for it
being to high was that the code that makes use of the effective_cache_size
tries very hard to account for what the current query would do to the cache
but doesn't take into account how many queries (on separate datasets!) are
currently begin executed (and competing for the same cache). On that box
we often have 100+ active connections and many looking at different big
datasets.
Cheers,
bene
Tom Lane <tgl@sss.pgh.pa.us> writes:
Well, the problem of "find out the box's physical RAM" is doubtless
solvable if we're willing to put enough sweat and tears into it, but
I'm dubious that it's worth the trouble. The harder part is how to know
if the box is supposed to be dedicated to the database. Bear in mind
that the starting point of this debate was the idea that we're talking
about an inexperienced DBA who doesn't know about any configuration knob
we might provide for the purpose.
It seems to me that pgfincore has the smarts we need to know about that,
and that Cédric has code and refenrences for making it work on all
platforms we care about (linux, bsd, windows for starters).
Then we could have a pretty decent snapshot of the information, and
maybe a background worker of some sort would be able to refresh the
information while the server is running.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Dimitri,
It seems to me that pgfincore has the smarts we need to know about that,
and that Cédric has code and refenrences for making it work on all
platforms we care about (linux, bsd, windows for starters).
Well, fincore is Linux-only, and for that matter only more recent
versions of linux. It would be great if we could just detect the RAM,
but then we *still* have to ask the user if this is a dedicated box or not.
Then we could have a pretty decent snapshot of the information, and
maybe a background worker of some sort would be able to refresh the
information while the server is running.
I don't see a background worker as necessary or even desirable; people
don't frequently add RAM to their systems. A manually callable command
would be completely adequate.
--
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
On Wed, Jan 9, 2013 at 3:39 PM, Josh Berkus <josh@agliodbs.com> wrote:
It seems to me that pgfincore has the smarts we need to know about that,
and that Cédric has code and refenrences for making it work on all
platforms we care about (linux, bsd, windows for starters).Well, fincore is Linux-only, and for that matter only more recent
versions of linux. It would be great if we could just detect the RAM,
but then we *still* have to ask the user if this is a dedicated box or not.
Not really. I'm convinced, and not only for e_c_s, that
autoconfiguration is within the realm of possibility.
However, since such a statement holds little weight without a patch
attached, I've been keeping it to myself (until I can invest the
effort needed for that patch).
In any case, as eavesdroppers can infer a cryptographic key by timing
operations or measuring power consumption, I'm pretty sure postgres
can infer cost metrics and/or time sharing with clever
instrumentation. The trick lies in making such instrumentation
uninstrusive.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Claudio,
Not really. I'm convinced, and not only for e_c_s, that
autoconfiguration is within the realm of possibility.
Hey, if you can do it, my hat's off to you.
In any case, as eavesdroppers can infer a cryptographic key by timing
operations or measuring power consumption, I'm pretty sure postgres
can infer cost metrics and/or time sharing with clever
instrumentation. The trick lies in making such instrumentation
uninstrusive.
... and not requiring a great deal of code maintenance for each and
every release of Linux and Windows.
Anyway, we could do something for 9.3 if we just make "available RAM" a
manual setting. Asking the user "how much RAM is available for
Postgres" is not a terribly difficult question.
--
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
Josh Berkus wrote:
The, shared_buffers, wal_buffers, and effective_cache_size (and possible
other future settings) can be set to -1. If they are set to -1, then we
use the figure:shared_buffers = available_ram * 0.25
(with a ceiling of 8GB)
wal_buffers = available_ram * 0.05
(with a ceiling of 32MB)
effective_cache_size = available_ram * 0.75
(with a floor of 128MB)If they are set to an amount, then we use the amount they are set to.
It would be nice to also automatically set work_mem, maint_work_mem,
temp_buffers, etc. based on the above, but that would be considerably
more difficult and require performance testing we haven't done yet.
My starting point for work_mem is usually:
work_mem = available_ram * 0.25 / max_connections
Like everything else, I might adjust from there, but it seems like
a sane starting point. Of course, one could easily argue for a
lower percentage or exclusion of some number of maint_work_mem
allocations.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Import Notes
Resolved by subject fallback
On Wed, Jan 9, 2013 at 12:38 AM, Benedikt Grundmann
<bgrundmann@janestreet.com> wrote:
For what it is worth even if it is a dedicated database box 75% might be way
too high. I remember investigating bad performance on our biggest database
server, that in the end turned out to be a too high setting of
effective_cache_size. From reading the code back then my rationale for it
being to high was that the code that makes use of the effective_cache_size
tries very hard to account for what the current query would do to the cache
but doesn't take into account how many queries (on separate datasets!) are
currently begin executed (and competing for the same cache). On that box we
often have 100+ active connections and many looking at different big
datasets.
I think that most busy installations either run a lot of small queries
(for which effective_cache_size is irrelevant), or a few large
queries. Your case is probably somewhat rare, and so as far as
defaults go, it would be sacrificed for the common good. The docs do
anticipate the need to account for multiple concurrent queries to be
discounted in deciding how to set effective_cache_size, but perhaps
the wording could be improved.
Out of curiosity, what did your queries look like after you lowered
effective_cache_size? Were there a lot of sequential scans, or did it
just choose different indexes than it had before? If a lot of
sequential scans, were they mostly on just a few tables that each had
many sequential scans going on simultaneously, or was it 100+
different tables each with one sequential scan going on? (You said
different big datasets, but I don't know if these are in different
tables, or in common tables with a column to distinguish them.)
Cheers,
Jeff
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Jan 8, 2013 at 08:40:44PM -0500, Andrew Dunstan wrote:
On 01/08/2013 08:08 PM, Tom Lane wrote:
Robert Haas <robertmhaas@gmail.com> writes:
On Tue, Jan 8, 2013 at 7:17 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
... And I don't especially like the idea of trying to
make it depend directly on the box's physical RAM, for the same
practical reasons Robert mentioned.For the record, I don't believe those problems would be particularly
hard to solve.Well, the problem of "find out the box's physical RAM" is doubtless
solvable if we're willing to put enough sweat and tears into it, but
I'm dubious that it's worth the trouble. The harder part is how to know
if the box is supposed to be dedicated to the database. Bear in mind
that the starting point of this debate was the idea that we're talking
about an inexperienced DBA who doesn't know about any configuration knob
we might provide for the purpose.I'd prefer to go with a default that's predictable and not totally
foolish --- and some multiple of shared_buffers seems like it'd fit the
bill.+1. That seems to be by far the biggest bang for the buck. Anything
else will surely involve a lot more code for not much more benefit.
I have developed the attached patch which implements an auto-tuned
effective_cache_size which is 4x the size of shared buffers. I had to
set effective_cache_size to its old 128MB default so the EXPLAIN
regression tests would pass unchanged.
I considered a new available_ram variable but that just gives us another
variable, and in a way shared_buffers is a fixed amount, while
effective_cache_size is an estimate, so I thought driving everything
from shared_buffers made sense.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
Attachments:
cache.difftext/x-diff; charset=us-asciiDownload+85-31
On Thu, Sep 5, 2013 at 3:01 AM, Bruce Momjian <bruce@momjian.us> wrote:
On Tue, Jan 8, 2013 at 08:40:44PM -0500, Andrew Dunstan wrote:
On 01/08/2013 08:08 PM, Tom Lane wrote:
Robert Haas <robertmhaas@gmail.com> writes:
On Tue, Jan 8, 2013 at 7:17 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
... And I don't especially like the idea of trying to
make it depend directly on the box's physical RAM, for the same
practical reasons Robert mentioned.For the record, I don't believe those problems would be particularly
hard to solve.Well, the problem of "find out the box's physical RAM" is doubtless
solvable if we're willing to put enough sweat and tears into it, but
I'm dubious that it's worth the trouble. The harder part is how to know
if the box is supposed to be dedicated to the database. Bear in mind
that the starting point of this debate was the idea that we're talking
about an inexperienced DBA who doesn't know about any configuration knob
we might provide for the purpose.I'd prefer to go with a default that's predictable and not totally
foolish --- and some multiple of shared_buffers seems like it'd fit the
bill.+1. That seems to be by far the biggest bang for the buck. Anything
else will surely involve a lot more code for not much more benefit.I have developed the attached patch which implements an auto-tuned
effective_cache_size which is 4x the size of shared buffers. I had to
set effective_cache_size to its old 128MB default so the EXPLAIN
regression tests would pass unchanged.
That's not really autotuning though. ISTM that making the *default* 4
x shared_buffers might make perfect sense, but do we really need to
hijack the value of "-1" for that? That might be useful for some time
when we have actual autotuning, that somehow inspects the system and
tunes it from there.
I also don't think it should be called autotuning, when it's just a
"smarter default value".
I like the feature, though, just not the packaging.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Magnus Hagander <magnus@hagander.net> writes:
On Thu, Sep 5, 2013 at 3:01 AM, Bruce Momjian <bruce@momjian.us> wrote:
I have developed the attached patch which implements an auto-tuned
effective_cache_size which is 4x the size of shared buffers. I had to
set effective_cache_size to its old 128MB default so the EXPLAIN
regression tests would pass unchanged.
That's not really autotuning though. ISTM that making the *default* 4
x shared_buffers might make perfect sense, but do we really need to
hijack the value of "-1" for that? That might be useful for some time
when we have actual autotuning, that somehow inspects the system and
tunes it from there.
Well, the real problem with this patch is that it documents what the
auto-tuning algorithm is; without that commitment, just saying "-1 means
autotune" might be fine.
Did you consider the alternative of just tweaking initdb to insert a
default for effective_cache_size that's 4x whatever it picks for
shared_buffers? That would probably be about 3 lines of code, and it
wouldn't nail down any particular server-side behavior.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Sep 5, 2013 at 06:14:33PM +0200, Magnus Hagander wrote:
I have developed the attached patch which implements an auto-tuned
effective_cache_size which is 4x the size of shared buffers. I had to
set effective_cache_size to its old 128MB default so the EXPLAIN
regression tests would pass unchanged.That's not really autotuning though. ISTM that making the *default* 4
x shared_buffers might make perfect sense, but do we really need to
hijack the value of "-1" for that? That might be useful for some time
when we have actual autotuning, that somehow inspects the system and
tunes it from there.I also don't think it should be called autotuning, when it's just a
"smarter default value".I like the feature, though, just not the packaging.
That "auto-tuning" text came from the wal_buffer documentation, which
does exactly this based on shared_buffers:
The contents of the WAL buffers are written out to disk at every
transaction commit, so extremely large values are unlikely to
provide a significant benefit. However, setting this value to at
least a few megabytes can improve write performance on a busy
--> server where many clients are committing at once. The auto-tuning
-----------
selected by the default setting of -1 should give reasonable
results in most cases.
I am fine with rewording and not using -1, but we should change the
wal_buffer default and documentation too then. I am not sure what other
value than -1 to use? 0? I figure if we ever get better auto-tuning,
we would just remove this functionality and make it better.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
