Re: W-TinyLfu for cache eviction
| От | Amit Kapila |
|---|---|
| Тема | Re: W-TinyLfu for cache eviction |
| Дата | |
| Msg-id | CAA4eK1LkQGNfeMYoryBVRc5g+8QKax6GSe4jtdjMNSx-dCf5nw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: W-TinyLfu for cache eviction (Vladimir Sitnikov <sitnikov.vladimir@gmail.com>) |
| Список | pgsql-hackers |
On Mon, Dec 14, 2015 at 12:18 PM, Vladimir Sitnikov <sitnikov.vladimir@gmail.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?
>
> > 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.
В списке pgsql-hackers по дате отправления: