RE: Having query cache in core

From: "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>
To: 'Robert Haas' <robertmhaas(at)gmail(dot)com>, 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-09 02:52:32
Message-ID: 0A3221C70F24FB45833433255569204D1F96E08F@G01JPEXMBYT05
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

From: Robert Haas [mailto:robertmhaas(at)gmail(dot)com]
> 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.

I have the same experience with our customers. Their batch applications suffered from performance compared to Oracle and SQL Server. Those apps repeatedly issued simple SELECT statements that retrieve a single row.

Regards
Takayuki Tsunakawa

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2018-05-09 02:59:15 Re: Should we add GUCs to allow partition pruning to be disabled?
Previous Message David Rowley 2018-05-09 02:31:39 Re: [HACKERS] path toward faster partition pruning