Re: CLOG contention, part 2

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема Re: CLOG contention, part 2
Дата
Msg-id CAMkU=1x7eeuT1os8r1ccnua6+7T0fqaFmE_=s5DZ313u7tFfjw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: CLOG contention, part 2  (Merlin Moncure <mmoncure@gmail.com>)
Ответы Re: CLOG contention, part 2  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Jeff Davis
Дата:
Сообщение: initdb and fsync
Следующее
От: Thom Brown
Дата:
Сообщение: Temp file missing during large pgbench data set