From: | Greg Smith <greg(at)2ndquadrant(dot)com> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: auto-sizing wal_buffers |
Date: | 2011-01-18 11:55:34 |
Message-ID: | 4D357FB6.60005@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Josh Berkus wrote:
> I think we can be more specific on that last sentence; is there even any
> *theoretical* benefit to settings above 16MB, the size of a WAL segment?
> Certainly there have been no test results to show any.
>
There was the set Marti just reminded about. The old wording suggested
big enough to fix a single transaction was big enough, and that let to
many people being confused and setting this parameter way too low.
Since it's possible I'm wrong about 16MB being the upper limit, I didn't
want the wording to specifically rule out people testing that size to
see what happens. We believe there's never any advantage due to the
forced wal segment switch, but having test results to the contrary
floating around keeps me from being too aggressive in how the wording
there goes.
--
Greg Smith 2ndQuadrant US greg(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us
"PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2011-01-18 12:09:27 | Re: Warning compiling pg_dump (MinGW, Windows XP) |
Previous Message | Greg Smith | 2011-01-18 11:50:52 | Re: auto-sizing wal_buffers |