| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Greg Stark <stark(at)mit(dot)edu> |
| Cc: | Shay Rojansky <roji(at)roji(dot)org>, Tatsuo Ishii <ishii(at)postgresql(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Slowness of extended protocol |
| Date: | 2016-07-31 21:34:29 |
| Message-ID: | 20160731213429.lxmdoa4vx2w3h3ye@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2016-07-31 22:26:00 +0100, Greg Stark wrote:
> I think you're looking at this the wrong way around. 30% of what?
> You're doing these simple read-only selects on a database that
> obviously is entirely in RAM. If you do the math on the numbers you
> gave above the simple protocol took 678 microseconds per transaction
> and the extended protocol took 876 microseconds. The difference is 198
> microseconds. I'm not sure exactly where those 200us are going and
> perhaps it could be lower but in what real-world query is it going to
> have a measurable impact on the total time?
FWIW, I've observed the same with (a bit) more complicated queries. A
part of this is that the extended protocol simply does
more. PQsendQueryGuts() sends Parse/Bind/Describe/Execute/Sync - that's
simply more work and data over the wire than a single Q message.
Whether that matters for a given workload or not, is a different
question, but I think it's pretty clear that it can for some.
Shay, are you using unnamed or named portals? There's already a shortcut
path for the former in some places.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2016-07-31 21:57:12 | Re: Slowness of extended protocol |
| Previous Message | Greg Stark | 2016-07-31 21:26:00 | Re: Slowness of extended protocol |