Skip site navigation (1) Skip section navigation (2)

Re: Mapping a database completly into Memory

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Vivek Khera <khera(at)kcilink(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Mapping a database completly into Memory
Date: 2003-07-30 22:10:24
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
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(at)sss(dot)pgh(dot)pa(dot)us> writes:
> TL> Franco Bruno Borghesi <franco(at)akyasociados(dot)com(dot)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(at)kciLink(dot)com       Rockville, MD       +1-240-453-8497
> AIM: vivekkhera Y!: vivek_khera
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
>       subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
>       message can get through to the mailing list cleanly

  Bruce Momjian                        |
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

In response to


pgsql-performance by date

Next:From: Bruce MomjianDate: 2003-07-30 22:12:53
Subject: Re: Mapping a database completly into Memory
Previous:From: Josh BerkusDate: 2003-07-30 20:42:24
Subject: Re: postgresql.conf

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group