Re: Mapping a database completly into Memory

Поиск
Список
Период
Сортировка
От Vivek Khera
Тема Re: Mapping a database completly into Memory
Дата
Msg-id x7oezde4sf.fsf@yertle.int.kciLink.com
обсуждение исходный текст
Ответ на Mapping a database completly into Memory  (Daniel Migowski <postgresql@Mig-O.de>)
Ответы Re: Mapping a database completly into Memory  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: Mapping a database completly into Memory  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список pgsql-performance
>>>>> "TL" == Tom Lane <tgl@sss.pgh.pa.us> writes:

TL> Franco Bruno Borghesi <franco@akyasociados.com.ar> writes:
>> wouldn't also increasing shared_buffers to 64 or 128 MB be a good
>> performance improvement? This way, pages belonging to heavily used
>> indexes would be already cached by the database itself.

TL> Not necessarily.  The trouble with large shared_buffers settings is you
TL> end up with lots of pages being doubly cached (both in PG's buffers and

I think if you do a lot of inserting/updating to your table, then more
SHM is better (and very high fsm settings), since you defer pushing
out the dirty pages to the disk.  For read-mostly, I agree that
letting the OS do the caching is a better way.


--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Vivek Khera, Ph.D.                Khera Communications, Inc.
Internet: khera@kciLink.com       Rockville, MD       +1-240-453-8497
AIM: vivekkhera Y!: vivek_khera   http://www.khera.org/~vivek/

В списке pgsql-performance по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Why performance improvement on converting subselect to a function ?
Следующее
От: Vivek Khera
Дата:
Сообщение: Re: Tuning PostgreSQL