>
> Bruce Momjian wrote:
> >
> > >
> > > Hi All
> > >
> > > I just upgraded to 128MB RAM, and really don't need ALL of it MOST of the
> > > time, and the main reason for it was to help with database speed.
> > >
> > > But then I got to thinking, is there a way to just semi-permently put a
> > > database into RAM? so that when a query is done it goes only to the image
> > > of the database in RAM, never even touching the hard drive. This would be
> > > enormasly faster on 50 ~ 100 (or what ever) MB databases, especially on
> > > those new boxes with that 6? or 10? nano second RAM. Especially if one
> > > could pick and chose which table(s) to put in RAM
> >
> > You can tune your OS to use most of that as buffer cache. However,
> > writes will be flushed to disk by postgresql fync, or the OS syncing
> > every so often, but not too bad. You can also up your postgres shared
> > memory buffers, though some OS's have a limit on that.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> ^^^^^^^^^^^^^^^^^^^^
> Could we use mmap (instead of shmem) with MAP_ANON flag to get more memory
> for shared buffer pool ?
> I'm using FreeBSD, man mmap says:
>
> MAP_ANON Map anonymous memory not associated with any specific file.
> The file descriptor used for creating MAP_ANON regions is
> used only for naming, and may be specified as -1 if no name
> is associated with the region.
>
> Vadim
>
I am going through my mailbox and I believe we never found a portable
way to allocate shared memory other than system V shared memory.
Increasing the amount of buffers beyond a certain amount requires a
kernel change.
Has anyone come up with a better way?
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)
