Re: Mapping a database completly into Memory
От | Bruce Momjian |
---|---|
Тема | Re: Mapping a database completly into Memory |
Дата | |
Msg-id | 200307302210.h6UMAOp15472@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: Mapping a database completly into Memory (Vivek Khera) |
Ответы |
Re: Mapping a database completly into Memory
(Vivek Khera)
|
Список | 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, )
I think it all depends on your working set. Having shared memory be smaller than you working set causes pages to have to be copied in from the kernel buffers (not a huge problem, but a small penalty), while having shared memory larger than the working set causes overhead of searching through all those buffers. --------------------------------------------------------------------------- Vivek Khera wrote: > >>>>> "TL" == Tom Lane <> writes: > > TL> 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. > > 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: Rockville, MD +1-240-453-8497 > AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/ > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to so that your > message can get through to the mailing list cleanly > -- Bruce Momjian | http://candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
В списке pgsql-performance по дате отправления: