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 <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/
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
>
--
Bruce Momjian | http://candle.pha.pa.us
pgman@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
