From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
Cc: | Peter Geoghegan <pg(at)heroku(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Clock sweep not caching enough B-Tree leaf pages? |
Date: | 2014-04-16 18:44:58 |
Message-ID: | 11258.1397673898@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Merlin Moncure <mmoncure(at)gmail(dot)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.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2014-04-16 18:59:45 | Re: The case against multixact GUCs |
Previous Message | Merlin Moncure | 2014-04-16 18:39:08 | Re: Clock sweep not caching enough B-Tree leaf pages? |