Re: Mapping a database completly into Memory

От: Bruce Momjian
Тема: Re: Mapping a database completly into Memory
Дата: ,
Msg-id: 200307302212.h6UMCrc15739@candle.pha.pa.us
(см: обсуждение, исходный текст)
Ответ на: 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, )

You make an interesting distinction that read/write needs more shared
memory.  I think this is because if you want to reused a read-only
shared buffer, you can just throw away the contents, while a dirty
buffer requires you to write it into the kernel before you can use it.

---------------------------------------------------------------------------

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 по дате сообщения:

От: Tom Lane
Дата:
Сообщение: Re: Why performance improvement on converting subselect
От: "Christopher Browne"
Дата:
Сообщение: Possible problem with DOMAIN evaluation?