From: | Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(dot)com> |
---|---|
To: | Ants Aasma <ants(dot)aasma(at)eesti(dot)ee> |
Cc: | Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: W-TinyLfu for cache eviction |
Date: | 2015-12-14 06:48:00 |
Message-ID: | CAB=Je-HFfjTTBuGnQnjN9hMkJEKncTriqjOnXfe+ArisLj-OVQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> a global lock would be good enough for a proof of concept that only
evaluates cache hit ratios.
I think emulator can be used to check hit ratios. That way we can see
how different algorithms affect hit ratio.
Is there a set of traces of "buffer load events"? (I did some Google
searches like "postgresql buffer cache trace" with no luck)
Is there an option that enables tracing of each requested buffer Id?
Frankly speaking, I've no access to PG instances with lots of data
(i.e. >10GiB).
> Maybe. Want to code it up?
That would be interesting, however: I'm not fluent at C. I've never
written multithreaded C code either. I understand what a cache line is
though.
Anyway, before hacking a prototype it makes sense to gather some traces.
Vladimir
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2015-12-14 06:50:57 | Re: Proposal: custom compression methods |
Previous Message | Michael Paquier | 2015-12-14 06:15:35 | Re: Function and view to retrieve WAL receiver status |