Re: Questions regarding contrib/tsearch - Mailing list pgsql-general

From Markus Wollny
Subject Re: Questions regarding contrib/tsearch
Date
Msg-id 2266D0630E43BB4290742247C8910575014CE331@dozer.computec.de
Whole thread Raw
In response to Questions regarding contrib/tsearch  ("Markus Wollny" <Markus.Wollny@computec.de>)
List 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

pgsql-general by date:

Previous
From: "Johnson, Shaunn"
Date:
Subject: reloading really big tables
Next
From: Bruce Momjian
Date:
Subject: O'Reilly Open Source Convention Report