Re: Process local hint bit cache

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Merlin Moncure <mmoncure(at)gmail(dot)com>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Process local hint bit cache
Date: 2011-03-30 15:43:53
Message-ID: 1301499595-sup-3545@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2011-03-30 15:47:09 Re: Another swing at JSON
Previous Message Alexey Klyukin 2011-03-30 15:40:00 proposal: a validator for configuration files