Re: SLRU

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

In response to

  • SLRU at 2013-06-17 07:52:50 from Soroosh Sardari

Browse pgsql-hackers by date

  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