Re: CLOG contention, part 2 - Mailing list pgsql-hackers

From Jeff Janes
Subject Re: CLOG contention, part 2
Date
Msg-id CAMkU=1x7eeuT1os8r1ccnua6+7T0fqaFmE_=s5DZ313u7tFfjw@mail.gmail.com
Whole thread Raw
In response to Re: CLOG contention, part 2  (Merlin Moncure <mmoncure@gmail.com>)
Responses Re: CLOG contention, part 2  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Fri, Jan 27, 2012 at 3:16 PM, Merlin Moncure <mmoncure@gmail.com> wrote:
> On Fri, Jan 27, 2012 at 4:05 PM, Jeff Janes <jeff.janes@gmail.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.
>
> right -- exactly.  but why stop at one page?

If you have more than one, you need code to decide which one to evict
(just free) every time you need a new one.  And every process needs to
be running this code, while the kernel is still going to need make its
own decisions for the entire system.  It seems simpler to just let the
kernel do the job for everyone.  Are you worried that a read syscall
is going to be slow even when the data is presumably cached in the OS?

Cheers,

Jeff


pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: initdb and fsync
Next
From: Thom Brown
Date:
Subject: Temp file missing during large pgbench data set