Re: Having query cache in core - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: Having query cache in core
Date
Msg-id CAFj8pRDkoZUTtQ9+qy4LF=eOyBKj_ktj8ptsRd=p4btCRHm+WQ@mail.gmail.com
Whole thread Raw
In response to Re: Having query cache in core  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Having query cache in core  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers


2018-05-07 19:52 GMT+02:00 Robert Haas <robertmhaas@gmail.com>:
On Sun, May 6, 2018 at 10:32 PM, Tatsuo Ishii <ishii@sraoss.co.jp> 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.

Caching results doesn't seem very useful to me, but caching plans
does.  I think the challenges are formidable, though.

My last customer has queries where planning time is 10 sec, unfortunately execution time in worst case (badly optimized is 200ms).

Can we introduce some planning cost to cache only expensive queries, or some hints for query plan control.

For interactive application only for one subset of queries the plan cache is interesting.

@1 There are long queries - the planning time is not significant (although can be high), and then plan cache is not important
@2 there are fast queries with fast planning time - usually we don't need plan cache too
@3 there are fast queries with long planning time - and then plan cache is very interesting - can be difficult to separate this case from @1.

Regards

Pavel




--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Refreshing findoidjoins for v11
Next
From: Michael Paquier
Date:
Subject: Re: Refreshing findoidjoins for v11