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?
If so, then I do not think that this cache will be able to demonstrate
some noticeable improvements of performance.
Yes, it is possible to expect that there is some subset of queries which
is used to be execute by application multiple times.
But most likely such query will be issued by different clients. It is
unlikely that the same client will execute the same query (with the same
parameter values)
more than once. Usually clients are using ORM which will in any case
somehow cache fetched data.
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
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).
Concerning result cache, I think it will be better to ask opinion of
mysql users: how useful it is.
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
