Re: Questions regarding contrib/tsearch

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

Browse pgsql-general by date

  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 ...