From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Having query cache in core |
Date: | 2018-05-08 11:52:07 |
Message-ID: | CA+TgmoY6hXx_-F4VJr18fb6J8yH=0TZpWbNaLvCg-pLV1_BPvA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, May 7, 2018 at 2:32 PM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
> 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.
That's not my experience. I agree that plan caching isn't important
for long-running queries, but I think it *is* potentially important
for fast queries with fast planning time. Even when the planning time
is fast, it can be a significant percentage of the execution time.
Not long ago, we had a case at EDB where a customer was getting custom
plans instead of generic plans and that resulted in a significant
reduction in TPS.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2018-05-08 11:53:32 | Re: perlcritic and perltidy |
Previous Message | Konstantin Knizhnik | 2018-05-08 11:33:48 | Re: Built-in connection pooling |