Re: Slowness of extended protocol - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Slowness of extended protocol
Date
Msg-id CA+TgmoYrnf+M+BWbLqWiyX9s5Knddk7xL_t7cXXpuGm8trvLqA@mail.gmail.com
Whole thread Raw
In response to Re: Slowness of extended protocol  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Aug 10, 2016 at 11:50 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> Sure, but I don't want the application to have to know about that, and
>> I don't really think the driver should need to know about that either.
>> Your point, as I understand it, is that sufficiently good query
>> caching in the driver can ameliorate the problem, and I agree with
>> that.
>
> I don't, actually.  If a particular application has a query mix that gets
> a good win from caching query plans, it should already be using prepared
> statements.  The fact that that's not a particularly popular thing to do
> isn't simply because people are lazy, it's because they've found out that
> it isn't worth the trouble for them.  Putting query caching logic into
> drivers isn't going to improve performance for such cases, and it could
> very possibly make things worse.  The driver is the place with the
> absolute least leverage for implementing caching; it has no visibility
> into either the application or the server.

I didn't mean to imply, in any way, that it is an ideal solution -
just that people use it successfully.

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



pgsql-hackers by date:

Previous
From: Michael Banck
Date:
Subject: Re: Is there a way around function search_path killing SQL function inlining?
Next
From: Stephen Frost
Date:
Subject: Re: Proposal for CSN based snapshots