| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(dot)com>, Shay Rojansky <roji(at)roji(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, Greg Stark <stark(at)mit(dot)edu>, Tatsuo Ishii <ishii(at)postgresql(dot)org> |
| Subject: | Re: Slowness of extended protocol |
| Date: | 2016-08-10 15:50:02 |
| Message-ID: | 17848.1470844202@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Banck | 2016-08-10 15:54:11 | Re: Is there a way around function search_path killing SQL function inlining? |
| Previous Message | Tom Lane | 2016-08-10 15:41:40 | Re: No longer possible to query catalogs for index capabilities? |