Re: How to keep a table in memory?

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Devrim GÜNDÜZ <devrim(at)CommandPrompt(dot)com>, 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: 2008-03-07 20:02:00
Message-ID: 200803072002.m27K20Y24115@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Added to TODO:

>
> * Consider allowing higher priority queries to have referenced buffer
> cache pages stay in memory longer
>
> http://archives.postgresql.org/pgsql-hackers/2007-11/msg00562.php

---------------------------------------------------------------------------

Tom Lane wrote:
> 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
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2008-03-07 20:06:24 Re: [PATCHES] a tsearch2 (8.2.4) dictionary that only filters out stopwords
Previous Message Heikki Linnakangas 2008-03-07 19:57:12 Re: Commitfest process