From: | "Markus Wollny" <Markus(dot)Wollny(at)computec(dot)de> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Questions regarding contrib/tsearch |
Date: | 2002-08-05 00:57:11 |
Message-ID: | 2266D0630E43BB4290742247C8910575014CE331@dozer.computec.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hi!
> > If so, what can I do to have all of the database in memory?
>
> Buy enough RAM to hold it ;-)
>
> If the database is being accessed heavily then it will tend to remain
> swapped in; you don't have to (and really can't) do anything to tweak
> the kernel-level and Postgres-level algorithms that determine this.
> What you want is to ensure there's enough RAM to hold not only all the
> database hotspots, but also all the other programs and working data
> that the server machine will be running.
>
> Check the actual size-on-disk of the tables and indexes you would like
> to be resident. (Do a vacuum, then look at pg_class.relpages
> for these
> items. See
> http://developer.postgresql.org/docs/postgres/diskusage.html
> for more info.)
>
> I would allow about 10MB of RAM per server process, plus a
> healthy chunk
> for the kernel and other programs.
Is that 10MB per process on top of total database size + shared_buffers?
In my case that would be roughly 1024MB database size + 2560 MB for
processes (256 max.) + 256 MB for shared_buffers, I think. Or did I
misunderstand you? Because in real life operation, RAM doesn't seem to
be a problem, as there's hardly any swap-activity and most of the
available RAM is used by system cache.
Regards,
Markus
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2002-08-05 01:06:34 | O'Reilly Open Source Convention Report |
Previous Message | Jim | 2002-08-05 00:46:51 | Primary Key: How Do I Generate One For Insert ... |