Skip site navigation (1) Skip section navigation (2)

Re: How to keep a table in memory?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Devrim GÜNDÜZ <devrim(at)CommandPrompt(dot)com>
Cc: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, adrobj <adrobj(at)yahoo(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: How to keep a table in memory?
Date: 2007-11-13 03:54:34
Message-ID: 29576.1194926074@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= <devrim(at)CommandPrompt(dot)com> writes:
> So, IMHO, saying "trust your OS + PostgreSQL" is not a 100% perfect
> approach for the people who are asking to keep their objects on RAM,
> even though I know that there is nothing we can say right now.

Well, nothing is a 100% solution.  But my opinion is that people who
think they are smarter than an LRU caching algorithm are typically
mistaken.  If the table is all that heavily used, it will stay in memory
just fine.  If it's not sufficiently heavily used to stay in memory
according to an LRU algorithm, maybe the memory space really should be
spent on something else.

Now there are certainly cases where a standard caching algorithm falls
down --- the main one I can think of offhand is where you would like to
give one class of queries higher priority than another, and so memory
space should preferentially go to tables that are needed by the first
class.  But if that's your problem, "pin these tables in memory" is
still an awfully crude solution to the problem.  I'd be inclined to
think instead about a scheme that lets references made by
higher-priority queries bump buffers' use-counts by more than 1,
or some other way of making the priority considerations visible to an
automatic cache management algorithm.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2007-11-13 04:03:11
Subject: Re: Simplifying Text Search
Previous:From: Devrim GÜNDÜZDate: 2007-11-13 03:23:02
Subject: Re: How to keep a table in memory?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group