Re: Clock sweep not caching enough B-Tree leaf pages? - Mailing list pgsql-hackers

From Merlin Moncure
Subject Re: Clock sweep not caching enough B-Tree leaf pages?
Date
Msg-id CAHyXU0wV28frnFi35Xm2NMxYs0kFSbGmbk5D8PotrDyhZEc5Rw@mail.gmail.com
Whole thread Raw
In response to Re: Clock sweep not caching enough B-Tree leaf pages?  (Peter Geoghegan <pg@heroku.com>)
Responses Re: Clock sweep not caching enough B-Tree leaf pages?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Apr 16, 2014 at 1:07 PM, Peter Geoghegan <pg@heroku.com> wrote:
> On Wed, Apr 16, 2014 at 10:56 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>> I don't think he's being unreasonable, and I don't understand why
>> you're getting bent out of shape about it.  You proposed a patch, he
>> articulated a problem, you don't want to fix it right now.  All of
>> which is fine.  Why the ad hominem accusations?
>
> I just think it's bad form to hold something like this to the same
> standards as a formal commitfest submission. I am well aware that the
> patch probably has several scalability issues.

In fairness to Andres, while *you* may know that issuing an expensive
syscall in a tight loop is on the list of Forbidden Things, a lot of
people don't and it's pretty reasonable to issue methodology
objections in order to get them documented.

Anyways, I'm still curious if you can post similar numbers basing the
throttling on gross allocation counts instead of time.  Meaning: some
number of buffer allocations has to have occurred before you consider
eviction.  Besides being faster I think it's a better implementation:
an intermittently loaded server will give more consistent behavior.

merlin



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: The case against multixact GUCs
Next
From: Tom Lane
Date:
Subject: Re: Clock sweep not caching enough B-Tree leaf pages?