Re: Clock with Adaptive Replacement

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Clock with Adaptive Replacement
Date: 2016-02-15 22:33:57
Message-ID: 12600.1455575637@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> writes:
> On 2/12/16 9:55 AM, Robert Haas wrote:
>> I think it's important to spend time and energy figuring out exactly
>> what the problems with our current algorithm are. We know in general
>> terms that usage counts tend to converge to either 5 or 0 and
>> therefore sometimes evict buffers both at great cost and almost

> Has anyone done testing on the best cap to usage count? IIRC 5 was
> pulled out of thin air.

My recollection is that there was some testing behind it ... but that
was back around 2005 so it seems safe to assume that that testing
is no longer terribly relevant. In particular, I'm sure it was tested
with shared_buffer counts far smaller than what we now consider sane.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2016-02-15 22:52:31 postgres_fdw vs. force_parallel_mode on ppc
Previous Message Tom Lane 2016-02-15 22:27:47 Re: Re: Reusing abbreviated keys during second pass of ordered [set] aggregates