Greg Stark wrote:
>
> Tom Lane <[EMAIL PROTECTED]> writes:
>
> > Suppose that you run a checkpoint every 5 minutes, and with the knob
> > you slow down the checkpoint to extend over say 3 minutes on average,
> > rather than the normal blast-it-out-as-fast-as-possible. Then you'll
> > be keeping
Tom Lane <[EMAIL PROTECTED]> writes:
> Suppose that you run a checkpoint every 5 minutes, and with the knob
> you slow down the checkpoint to extend over say 3 minutes on average,
> rather than the normal blast-it-out-as-fast-as-possible. Then you'll
> be keeping an average of 8 minutes worth of
Bruce Momjian writes:
> Greg Stark wrote:
>> Put another way, we already have such a clock scan, it's called checkpoint.
>> You could have checkpoint delay between each page write long enough to spread
>> the checkpoint i/o out over a configurable amount of time -- say half the
>> checkpoint inter
Greg Stark wrote:
>
> Tom Lane <[EMAIL PROTECTED]> writes:
>
> > Maybe we need a hybrid approach: clean a few percent of the LRU end of
> > the ARC list in order to keep backends from blocking on writes, plus run
> > a clock scan to keep checkpoints from having to do much.
>
> Well if you just
On Mon, Dec 20, 2004 at 11:20:46PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> Exactly. But 1% would be uselessly small with this definition. Offhand
> >> I'd think something like 50% might be a starting point; maybe even more.
> >> What that says is that a page isn't
On Tue, 2004-12-21 at 15:26, Tom Lane wrote:
> Richard Huxton writes:
> > However, one thing you can say is that if block B hasn't been written to
> > since you last checked, then any blocks older than that haven't been
> > written to either.
>
> [ itch... ] Can you? I don't recall exactly wh
Tom Lane <[EMAIL PROTECTED]> writes:
> Maybe we need a hybrid approach: clean a few percent of the LRU end of
> the ARC list in order to keep backends from blocking on writes, plus run
> a clock scan to keep checkpoints from having to do much.
Well if you just keep note of when the last clock
On Tue, Dec 21, 2004 at 10:26:48AM -0500, Tom Lane wrote:
> Richard Huxton <[EMAIL PROTECTED]> writes:
> > However, one thing you can say is that if block B hasn't been written to
> > since you last checked, then any blocks older than that haven't been
> > written to either.
>
> [ itch... ] Can
Richard Huxton <[EMAIL PROTECTED]> writes:
> However, one thing you can say is that if block B hasn't been written to
> since you last checked, then any blocks older than that haven't been
> written to either.
[ itch... ] Can you? I don't recall exactly when a block gets pushed
up the ARC list
[EMAIL PROTECTED] wrote:
Tom Lane <[EMAIL PROTECTED]> wrote on 21.12.2004, 05:05:36:
Bruce Momjian writes:
I am confused. If we change the percentage to be X% of the entire
buffer cache, and we set it to 1%, and we exit when either the dirty
pages or % are reached, don't we end up just scanning t
> If we don't start where we left off, I am thinking if you do a lot of
> writes then do nothing, the next checkpoint would be huge because a lot
> of the LRU will be dirty because the bgwriter never got to it.
I think the problem is, that we don't see wether a "read hot"
page is also "write hot
Tom Lane <[EMAIL PROTECTED]> wrote on 21.12.2004, 05:05:36:
> Bruce Momjian writes:
> > I am confused. If we change the percentage to be X% of the entire
> > buffer cache, and we set it to 1%, and we exit when either the dirty
> > pages or % are reached, don't we end up just scanning the first 1
Tom Lane <[EMAIL PROTECTED]> wrote on 21.12.2004, 07:32:52:
> Gavin Sherry writes:
> > I was also thinking of benchmarking the effect of changing the algorithm
"changing the algorithm" is a phrase that sends shivers up my spine. My
own preference is towards some change, but as minimal as possibl
Gavin Sherry <[EMAIL PROTECTED]> writes:
> I was also thinking of benchmarking the effect of changing the algorithm
> in StrategyDirtyBufferList(): currently, for each iteration of the loop we
> read a buffer from each of T1 and T2. I was wondering what effect reading
> T1 first then T2 and vice ve
Gavin Sherry wrote:
> Neil and I spoke with Jan briefly last week and he mentioned a few
> different approaches he'd been tossing over. Firstly, for alternative
> runs, start X% on from the LRU, so that we aren't scanning clean buffers
> all the time. Secondly, follow something like the approach yo
On Mon, 20 Dec 2004, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Exactly. But 1% would be uselessly small with this definition. Offhand
> >> I'd think something like 50% might be a starting point; maybe even more.
> >> What that says is that a page isn't
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Exactly. But 1% would be uselessly small with this definition. Offhand
> >> I'd think something like 50% might be a starting point; maybe even more.
> >> What that says is that a page isn't a candidate to be writ
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Exactly. But 1% would be uselessly small with this definition. Offhand
>> I'd think something like 50% might be a starting point; maybe even more.
>> What that says is that a page isn't a candidate to be written out by the
>> bgwriter
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I am confused. If we change the percentage to be X% of the entire
> > buffer cache, and we set it to 1%, and we exit when either the dirty
> > pages or % are reached, don't we end up just scanning the first 1% of
> > the cache over an
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I am confused. If we change the percentage to be X% of the entire
> buffer cache, and we set it to 1%, and we exit when either the dirty
> pages or % are reached, don't we end up just scanning the first 1% of
> the cache over and over again?
Exactly. B
Bruce Momjian <[EMAIL PROTECTED]> writes:
> You need a "clock sweep" like BSD uses (and probably others).
No, that's *fundamentally* wrong.
The reason we are going to the trouble of maintaining a complicated
cache algorithm like ARC is so that we can tell the heavily used pages
from the lesser us
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I think the ideal solution would be to remove bgwriter_percent or change
> > it to be a percentage of all buffers, not just dirty buffers, so we
> > don't have to scan the entire list. If we set the new value to 10% with
> > a delay o
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I think the ideal solution would be to remove bgwriter_percent or change
> it to be a percentage of all buffers, not just dirty buffers, so we
> don't have to scan the entire list. If we set the new value to 10% with
> a delay of 1 second, and the bgwrit
We are now packaging RC2. If nothing comes up after RC2 is released, we
can move to final release.
The open items list is attached. The doc changes can be easily
completed before final. The only code issue left is with bgwriter. We
always knew we needed to find better defaults for its paramete
24 matches
Mail list logo
