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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2007-11-13 04:03:11 | Re: Simplifying Text Search |
Previous Message | Devrim GÜNDÜZ | 2007-11-13 03:23:02 | Re: How to keep a table in memory? |