| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
| Cc: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, garsthe1st(at)gmail(dot)com, dxahtepb(at)gmail(dot)com, geymer_98(at)mail(dot)ru, dafi913(at)yandex(dot)ru, edigaryev(dot)ig(at)phystech(dot)edu, Benjamin Manes <ben(dot)manes(at)gmail(dot)com> |
| Subject: | Re: [Patch][WiP] Tweaked LRU for shared buffers |
| Date: | 2019-02-15 23:51:19 |
| Message-ID: | CAH2-WznEK0RM2cMnt0Wvwtp_9G7R+1Aru7x+d5Zn7QWJK1XzXA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Feb 15, 2019 at 3:30 PM Tomas Vondra
<tomas(dot)vondra(at)2ndquadrant(dot)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. 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.
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tomas Vondra | 2019-02-16 00:22:36 | Re: [Patch][WiP] Tweaked LRU for shared buffers |
| Previous Message | Tomas Vondra | 2019-02-15 23:30:26 | Re: [Patch][WiP] Tweaked LRU for shared buffers |