Re: [Patch][WiP] Tweaked LRU for shared buffers - Mailing list pgsql-hackers

From Tomas Vondra
Subject Re: [Patch][WiP] Tweaked LRU for shared buffers
Date
Msg-id 965cc34b-39f6-87eb-b157-84a2ea104419@2ndquadrant.com
Whole thread Raw
In response to Re: [Patch][WiP] Tweaked LRU for shared buffers  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: [Patch][WiP] Tweaked LRU for shared buffers
List pgsql-hackers
On 2/16/19 12:51 AM, Peter Geoghegan wrote:
> On Fri, Feb 15, 2019 at 3:30 PM Tomas Vondra
> <tomas.vondra@2ndquadrant.com> wrote:
>> That TPS chart looks a bit ... wild. How come the master jumps so much
>> up and down? That's a bit suspicious, IMHO.
> 
> Somebody should write a patch to make buffer eviction completely 
> random, without aiming to get it committed. That isn't as bad of a 
> strategy as it sounds, and it would help with assessing improvements 
> in this area.
> 
> We know that the cache replacement algorithm behaves randomly when 
> there is extreme contention, while also slowing everything down due
> to maintaining the clock.

Possibly, although I still find it strange that the throughput first
grows, then at shared_buffers 1GB it drops, and then at 3GB it starts
growing again. Considering this is on 200GB data set, I doubt the
pressure/contention is much different with 1GB and 3GB, but maybe it is.

> A unambiguously better caching algorithm would at a minimum be able
> to beat our "cheap random replacement" prototype as well as the
> existing clocksweep algorithm in most or all cases. That seems like a
> reasonably good starting point, at least.
> 

Yes, comparison to cheap random replacement would be an interesting
experiment.


regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: [Patch][WiP] Tweaked LRU for shared buffers
Next
From: Benjamin Manes
Date:
Subject: Re: [Patch][WiP] Tweaked LRU for shared buffers