Re: Priority table or Cache table - Mailing list pgsql-hackers

From Hans-Jürgen Schönig
Subject Re: Priority table or Cache table
Date
Msg-id 156928B0-02FF-4AD9-85B7-7FE69D40C4B2@cybertec.at
Whole thread Raw
In response to Re: Priority table or Cache table  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Priority table or Cache table
List pgsql-hackers
On 20 Feb 2014, at 01:38, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Haribabu Kommi <kommi.haribabu@gmail.com> writes:
>> I want to propose a new feature called "priority table" or "cache table".
>> This is same as regular table except the pages of these tables are having
>> high priority than normal tables. These tables are very useful, where a
>> faster query processing on some particular tables is expected.
>
> Why exactly does the existing LRU behavior of shared buffers not do
> what you need?
>
> I am really dubious that letting DBAs manage buffers is going to be
> an improvement over automatic management.
>
>             regards, tom lane



the reason for a feature like that is to define an area of the application which needs more predictable runtime
behaviour.
not all tables are created equals in term of importance.

example: user authentication should always be supersonic fast while some reporting tables might gladly be forgotten
evenif they happened to be in use recently. 

i am not saying that we should have this feature.
however, there are definitely use cases which would justify some more control here.
otherwise people will fall back and use dirty tricks sucks as “SELECT count(*)” or so to emulate what we got here.
many thanks,
    hans


--
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de




pgsql-hackers by date:

Previous
From: Kohei KaiGai
Date:
Subject: Re: sepgsql: label regression test failed
Next
From: Craig Ringer
Date:
Subject: Re: SKIP LOCKED DATA (work in progress)