Re: our buffer replacement strategy is kind of lame

From: daveg <daveg(at)sonic(dot)net>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: our buffer replacement strategy is kind of lame
Date: 2011-08-12 22:42:46
Message-ID: 20110812224246.GN14353@sonic.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Aug 12, 2011 at 01:28:49PM +0100, Simon Riggs wrote:
> I think there are reasonable arguments to make
>
> * prefer_cache = off (default) | on a table level storage parameter,
> =on will disable the use of BufferAccessStrategy
>
> * make cache_spoil_threshold a parameter, with default 0.25
>
> Considering the world of very large RAMs in which we now live, some
> control of the above makes sense.

As long as we are discussion cache settings for tables, I have a client
who would like to be able to lock specific tables and indexes into cache
as they have strict response time requirements for particular queries.
At the moment they are running postgres with a tablespace on ramfs and
taking frequent backups, but this is not optimal.

-dg

--
David Gould daveg(at)sonic(dot)net 510 536 1443 510 282 0869
If simplicity worked, the world would be overrun with insects.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message daveg 2011-08-12 23:19:37 OperationalError: FATAL: lock AccessShareLock on object 0/1260/0 is already
Previous Message daveg 2011-08-12 22:20:22 Re: VACUUM FULL versus system catalog cache invalidation