Re: Priority table or Cache table

Поиск
Список
Период
Сортировка
От Hans-Jürgen Schönig
Тема Re: Priority table or Cache table
Дата
Msg-id 156928B0-02FF-4AD9-85B7-7FE69D40C4B2@cybertec.at
обсуждение исходный текст
Ответ на Re: Priority table or Cache table  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Priority table or Cache table
Список 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 по дате отправления:

Предыдущее
От: Kohei KaiGai
Дата:
Сообщение: Re: sepgsql: label regression test failed
Следующее
От: Craig Ringer
Дата:
Сообщение: Re: SKIP LOCKED DATA (work in progress)