Skip site navigation (1) Skip section navigation (2)

Re: CLOG contention, part 2

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: CLOG contention, part 2
Date: 2012-01-29 18:59:20
Message-ID: CA+U5nM+Vefd3pz9_WugdTLpia97dwH==DCSW+iQQqZEk6S6rZA@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Sat, Jan 28, 2012 at 1:52 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:

>> Also, I think the general approach is wrong.  The only reason to have
>> these pages in shared memory is that we can control access to them to
>> prevent write/write and read/write corruption.  Since these pages are
>> never written, they don't need to be in shared memory.   Just read
>> each page into backend-local memory as it is needed, either
>> palloc/pfree each time or using a single reserved block for the
>> lifetime of the session.  Let the kernel worry about caching them so
>> that the above mentioned reads are cheap.
>
> Will think on that.

For me, there are arguments both ways as to whether it should be in
shared or local memory.

The one factor that makes the answer "shared" for me is that its much
easier to reuse existing SLRU code. We dont need to invent a new way
of cacheing/access etc. We just rewire what we already have. So
overall, the local/shared debate is much less important that the
robustness/code reuse angle. That's what makes this patch fairly
simple.

-- 
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

In response to

pgsql-hackers by date

Next:From: Kohei KaiGaiDate: 2012-01-29 19:39:19
Subject: Re: pgsql_fdw, FDW for PostgreSQL server
Previous:From: Tom LaneDate: 2012-01-29 17:00:49
Subject: Re: patch for parallel pg_dump

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group