Tom Lane wrote:
> Greg Smith <[EMAIL PROTECTED]> writes:
> > On Sun, 20 Jan 2008, Tom Lane wrote:
> >> I think the main problem is the qualifying clause up front in a place
> >> of prominence. Here's a V3 try
>
> > That one looks good to me. These are small details but better to get it
> > righ
Greg Smith <[EMAIL PROTECTED]> writes:
> On Sun, 20 Jan 2008, Tom Lane wrote:
>> I think the main problem is the qualifying clause up front in a place
>> of prominence. Here's a V3 try
> That one looks good to me. These are small details but better to get it
> right now.
OK, committed. Back t
On Sun, 20 Jan 2008, Tom Lane wrote:
I think the main problem is the qualifying clause up front in a place
of prominence. Here's a V3 try
That one looks good to me. These are small details but better to get it
right now.
--
* Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore
Greg Smith <[EMAIL PROTECTED]> writes:
> There is nothing incorrect here, it's just not as clear as it could be.
> Here's a V2 that tries to clear that up:
> Unless limited by bgwriter_lru_maxpages, the number of dirty
> buffers written in each round is based on the number of new buffers that
>
On Sun, 20 Jan 2008, Alvaro Herrera wrote:
Is the bgwriter_lru_multiplier parameter a limit on the number to scan
or to write? GUC and docs seem to contradict one another.
It adjusts the target for how many clean buffers it wants to either find
or create. This always increases the number of
Is the bgwriter_lru_multiplier parameter a limit on the number to scan
or to write? GUC and docs seem to contradict one another. GUC says
#: utils/misc/guc.c:1834
#, fuzzy
msgid "Background writer multiplier on average buffers to scan per round."
The docs say
Unless limited by bgwrite
