Re: Having query cache in core

From: Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>
To: "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Having query cache in core
Date: 2018-05-07 08:41:59
Message-ID: 7e22b5ec-5ea2-679c-3bb3-c296f6436a0a@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 07.05.2018 11:24, Tsunakawa, Takayuki wrote:
> From: Konstantin Knizhnik [mailto:k(dot)knizhnik(at)postgrespro(dot)ru]
>> But I think it is better to start first with
>> 1. Global prepared statements cache
>> 2. Global catalog cache
>> 3. Global relation cache
> May I ask why prepared statements need to precede catalog and relation caches? We're suffering from the bloat of catalog and relation caches, and are thinking of proposing placing those caches in shared memory.
>

Sorry, I didn't assume some particular order here. Yes, shared catalog
and relation cache seems to be more important to implement first.

>
>> Switch to global caches seems to be a challenged task, requiring a lot
>> of changes in Postgres core.
>> But I think that sometime we will have to implement them in any case (as
>> it was done in most of other DBMSes).
> Agreed. I respect your attitude toward revolutionizing PostgreSQL.
>
>
>> Concerning result cache, I think it will be better to ask opinion of
>> mysql users: how useful it is.
> And possibly Oracle Database users, as Oracle implemented it relatively recently, IIRC.
>
> Regards
> Takayuki Tsunakawa
>

--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuo Ishii 2018-05-07 08:58:44 Re: Having query cache in core
Previous Message Hartmut Holzgraefe 2018-05-07 08:41:11 Re: Having query cache in core