t: Re: [HACKERS] Possible performance improvement: buffer replacement policy
In-reply-to: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
Comments: In-reply-to Bruce Momjian <[EMAIL PROTECTED]>
message dated "Mon, 16 Oct 2000 11:41:41 -0400"
Date: Mon, 16 Oct 2000 1
> So, we probably should put new free dirty buffer just before first
> undirty one in LRU.
Ops - new free UNdirty buffer before first DIRTY one in LRU,
sorry -:)
Vadim
> > Tom, did we ever test this? I think we did and found that
> > it was the same or worse, right?
>
> I tried it and didn't see any noticeable improvement on the particular
> test case I was using, so I got discouraged and didn't pursue the idea
> further. I'd like to come back to it someday,
I will throw the email into the optimizer TODO.detail file.
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom, did we ever test this? I think we did and found that it was the
> > same or worse, right?
>
> I tried it and didn't see any noticeable improvement on the particular
> test case I wa
Threw it into TODO.detail performance, not optimizer.
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom, did we ever test this? I think we did and found that it was the
> > same or worse, right?
>
> I tried it and didn't see any noticeable improvement on the particular
> test case I was usin
;
> To: Bruce Momjian <[EMAIL PROTECTED]>
> cc: [EMAIL PROTECTED]
> Subject: Re: [HACKERS] Possible performance improvement: buffer replacement policy
> In-reply-to: <[EMAIL PROTECTED]>
> References: <[EMAIL PROTECTED]>
> Comments: In-reply-to Bruce Momjian &l
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom, did we ever test this? I think we did and found that it was the
> same or worse, right?
I tried it and didn't see any noticeable improvement on the particular
test case I was using, so I got discouraged and didn't pursue the idea
further. I'd lik
Tom, did we ever test this? I think we did and found that it was the
same or worse, right?
> Those of you with long memories may recall a benchmark that Edmund Mergl
> drew our attention to back in May '99. That test showed extremely slow
> performance for updating a table with many indexes (a
> > It looks like it wouldn't take too much work to replace
> > shared buffers on the basis of LRU-2 instead of LRU, so
> > I'm thinking about trying it.
> >
> > Has anyone looked into this area? Is there a better method to try?
>
> Sounds like a perfect idea. Good luck. :-)
Hmm, how much t
> (If you subscribe to the ACM digital library, you can get a PDF of this
> from there.) This article argues that standard LRU buffer management is
> inherently not great for database caches, and that it's much better to
> replace pages on the basis of time since the K'th most recent reference,
>
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> It looks like it wouldn't take too much work to replace shared buffers
>> on the basis of LRU-2 instead of LRU, so I'm thinking about trying it.
>>
>> Has anyone looked into this area? Is there a better method to try?
> Sounds like a perfect idea. G
11 matches
Mail list logo
