From: | Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com> |
---|---|
To: | Soroosh Sardari <soroosh(dot)sardari(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: SLRU |
Date: | 2013-06-17 08:06:01 |
Message-ID: | CABOikdNqOXAsdPwR3NVTCKAu09PgtA2WsAzvGsS8VRri=AS0sw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jun 17, 2013 at 1:22 PM, Soroosh Sardari
<soroosh(dot)sardari(at)gmail(dot)com>wrote:
> Hey
>
> I was reading the multi transaction log manager, multixact.c.
> I didn't get what SLRU does.
>
> I want the goal of this module, and why we use it.
> I'm kind of newbie, be patient with me ;)
>
>
Did you look at src/backend/access/transam/slru.c ? The first para in that
file is quite explanatory:
* We use a simple least-recently-used scheme to manage a pool of page
* buffers. Under ordinary circumstances we expect that write
* traffic will occur mostly to the latest page (and to the just-prior
* page, soon after a page transition). Read traffic will probably touch
* a larger span of pages, but in any case a fairly small number of page
* buffers should be sufficient. So, we just search the buffers using plain
* linear search; there's no need for a hashtable or anything fancy.
* The management algorithm is straight LRU except that we will never swap
* out the latest page (since we know it's going to be hit again
eventually).
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
From | Date | Subject | |
---|---|---|---|
Next Message | Dimitri Fontaine | 2013-06-17 09:10:04 | Re: Hard limit on WAL space used (because PANIC sucks) |
Previous Message | Pavan Deolasee | 2013-06-17 08:03:01 | Re: Patch for fail-back without fresh backup |