On 2/16/19 12:51 AM, Peter Geoghegan wrote: > On Fri, Feb 15, 2019 at 3:30 PM Tomas Vondra > <tomas.von...@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
