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

From Tom Lane
Subject Re: Questions regarding contrib/tsearch
Date
Msg-id 14532.1028316618@sss.pgh.pa.us
Whole thread Raw
In response to Re: Questions regarding contrib/tsearch  (Andrew Sullivan <andrew@libertyrms.info>)
Responses Re: Questions regarding contrib/tsearch  (Andrew Sullivan <andrew@libertyrms.info>)
List pgsql-general
Andrew Sullivan <andrew@libertyrms.info> writes:
> On Fri, Aug 02, 2002 at 09:39:54AM -0400, Tom Lane wrote:
>> 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.

> I was wondering: is there an in-principle reason that there isn't any
> mechanism for locking a table in memory, or is it just that no-one
> has ever done it?

Why would you?  If the table is being heavily accessed then it will stay
in memory.  If it gets dropped from memory then the memory was needed
for something else that's more heavily used at the moment.

I'll grant you that buffer management algorithms are not perfect,
but I really doubt that "lock this table in core" is an improvement
over letting the system do its thing.

            regards, tom lane

pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: How i can empty the buffers of a db
Next
From: Tom Lane
Date:
Subject: Re: b1 OR b2 <-> ( CASE WHEN b1 THE true ELSE b2 END ): performance bottleneck on logical OR