From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(dot)com> |
Cc: | Ants Aasma <ants(dot)aasma(at)eesti(dot)ee>, 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 08:34:21 |
Message-ID: | CAA4eK1LkQGNfeMYoryBVRc5g+8QKax6GSe4jtdjMNSx-dCf5nw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Dec 14, 2015 at 12:18 PM, Vladimir Sitnikov <
sitnikov(dot)vladimir(at)gmail(dot)com> wrote:
> > 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?
>
To get the detailed trace for each buffer, I think you can use dynamic
tracing as explained in documentation [1].
Another simple way could be to use:
Explain (Analyze, Buffers) <sql_statement>
This will give blocks hit and read numbers which could be useful in your
experiments.
[1] - http://www.postgresql.org/docs/devel/static/dynamic-trace.html
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2015-12-14 08:51:41 | Re: [PoC] Asynchronous execution again (which is not parallel) |
Previous Message | Kyotaro HORIGUCHI | 2015-12-14 08:34:18 | Re: [PoC] Asynchronous execution again (which is not parallel) |