Re: Mapping a database completly into Memory

От: Tom Lane
Тема: Re: Mapping a database completly into Memory
Дата: ,
Msg-id: 15250.1059411499@sss.pgh.pa.us
(см: обсуждение, исходный текст)
Ответ на: Re: Mapping a database completly into Memory  (Josh Berkus)
Список: pgsql-performance

Скрыть дерево обсуждения

Mapping a database completly into Memory  (Daniel Migowski, )
 Re: Mapping a database completly into Memory  (Tom Lane, )
  Re: Mapping a database completly into Memory  (Josh Berkus, )
   Re: Mapping a database completly into Memory  (Franco Bruno Borghesi, )
    Re: Mapping a database completly into Memory  (Tom Lane, )
     Re: Mapping a database completly into Memory  (Andrew Sullivan, )
 Re: Mapping a database completly into Memory  (Josh Berkus, )
  Re: Mapping a database completly into Memory  (Franco Bruno Borghesi, )
  Re: Mapping a database completly into Memory  (Tom Lane, )
 Re: Mapping a database completly into Memory  (Vivek Khera, )
  Re: Mapping a database completly into Memory  (Bruce Momjian, )
   Re: Mapping a database completly into Memory  (Vivek Khera, )
  Re: Mapping a database completly into Memory  (Bruce Momjian, )

Josh Berkus <> writes:
>> If we had a portable way
>> of preventing the kernel from caching the same page, it would make more
>> sense to run with large shared_buffers.

> Really?  I thought we wanted to move the other way ... that is, if we could
> get over the portability issues, eliminate shared_buffers entirely and rely
> completely on the OS cache.

That seems unlikely to happen: there are cache-coherency problems if you
don't do your page-level access through shared buffers.  Some have
suggested using mmap access to the data files in place of shared memory,
but that introduces a slew of issues of its own.  It might happen but
I'm not holding my breath.

            regards, tom lane


В списке pgsql-performance по дате сообщения:

От: Josh Berkus
Дата:
Сообщение: Re: Rebuild indexes
От: Tom Lane
Дата:
Сообщение: Re: [ADMIN] Rebuild indexes