Re: Clock sweep not caching enough B-Tree leaf pages?

Merlin Moncure <mmoncure@gmail.com>

From: Merlin Moncure <mmoncure@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Peter Geoghegan <pg@heroku.com>, Robert Haas <robertmhaas@gmail.com>, Andres Freund <andres@2ndquadrant.com>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2014-04-16T19:26:05Z
Lists: pgsql-hackers
On Wed, Apr 16, 2014 at 1:44 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Merlin Moncure <mmoncure@gmail.com> writes:
>> 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.
>
> Yeah --- I think wall-clock-based throttling is fundamentally the wrong
> thing anyway.  Are we going to start needing a CPU speed measurement to
> tune the algorithm with?  Not the place to be going.  But driving it off
> the number of allocations that've been done could be sensible.  (OTOH,
> that means you need a central counter, which itself would be a
> bottleneck.)

sure -- note we already track that in BufferStrategyControl
(everything in buffer allocation is already centrally managed
essentially).

        /*
         * Statistics.  These counters should be wide enough that they can't
         * overflow during a single bgwriter cycle.
         */
        uint32          completePasses; /* Complete cycles of the clock sweep */
        uint32          numBufferAllocs;        /* Buffers allocated
since last reset */

merlin


Commits

  1. Replace the BufMgrLock with separate locks on the lookup hashtable and