Re: Process local hint bit cache - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Process local hint bit cache
Date
Msg-id 1301499595-sup-3545@alvh.no-ip.org
Whole thread Raw
In response to Re: Process local hint bit cache  (Merlin Moncure <mmoncure@gmail.com>)
Responses Re: Process local hint bit cache
List pgsql-hackers
Excerpts from Merlin Moncure's message of mié mar 30 12:14:20 -0300 2011:

> It is very different -- the slru layer is in shared memory and
> requires locks to access.   The entire point is trying to avoid
> accessing this structure in tight code paths.  I'm actually very
> skeptical the slru layer provides any benefit at all.  I bet it would
> be cheaper just mmap in the pages directly (as Heikki is also
> speculating).

Maybe it would be useful to distinguish the last SLRU page(s) (the one
where clog writing actually takes place) from the older ones (which only
ever see reading).  You definitely need locks to be able to access the
active pages, but all the rest could be held as mmapped and accessed
without locks because they never change (except to be truncated away).
You know that any page behind RecentXmin is not going to be written
anymore, so why go through all the locking hoops?

-- 
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support


pgsql-hackers by date:

Previous
From: Dimitri Fontaine
Date:
Subject: Re: Another swing at JSON
Next
From: Alexey Klyukin
Date:
Subject: proposal: a validator for configuration files