> On 07.05.2018 05:32, Tatsuo Ishii wrote:
>> Does anybody think having in-memory query result cache in core is a
>> good idea? From the experience of implementing the feature in
>> Pgpool-II, I would think this is not terribly hard job. But first of
>> all I'm wondering if there's a demand for the feature.
>
> Do you want to implement this cache locally in backend?
No, as a global cache, if I employ the design of Pgpool-II. Pgpool-II
offsers two types of query result cache: in the shared memory or using
external cache server (i.e. memcached).
> Global result cache (like one used in mySQL) may be more efficient.
> But I think it is better to start first with
> 1. Global prepared statements cache
> 2. Global catalog cache
> 3. Global relation cache
Are they totally different story from query result cache, no?
> Concerning result cache, I think it will be better to ask opinion of
> mysql users: how useful it is.
One RedShift user used to use the query result cache in Pgpool-II (I
think they moved to more application layer cache). So I just wonder if
there is any demand for in-core cache.
I think one merit to have it in-core is, it's easy to get catalog
info: Pgpool-II works hard to figure out if the query result is safe
to cache or not. e.g. the SELECT uses stable functions or not, uses
temp tables or not. In-core cache eliminates the hard work (no need to
say cache invalidation). On the other hand, query cache definitely
avoid heavy SELECT run twice, but user need to connect to PostgreSQL
if it's in-core. Having query cache in the middle ware like Pgpool-II
could completely avoid accessing PostgreSQL.
Anyway, I already have a query cache in Pgpool-II. So unless users are
eager to have it in core, I will not be so interested in implementing
it.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
