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
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 |