Re: Mapping a database completly into Memory
От | Tom Lane |
---|---|
Тема | Re: Mapping a database completly into Memory |
Дата | |
Msg-id | 10185.1059409557@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Mapping a database completly into Memory (Franco Bruno Borghesi) |
Ответы |
Re: Mapping a database completly into Memory
(Andrew Sullivan)
|
Список | 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, )
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, )
Franco Bruno Borghesi <> 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. Not necessarily. The trouble with large shared_buffers settings is you end up with lots of pages being doubly cached (both in PG's buffers and in the kernel's disk cache), thus wasting RAM. 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. regards, tom lane
В списке pgsql-performance по дате отправления: