| From: | Shay Rojansky <roji(at)roji(dot)org> |
|---|---|
| To: | Tatsuo Ishii <ishii(at)postgresql(dot)org> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Slowness of extended protocol |
| Date: | 2016-07-31 15:05:28 |
| Message-ID: | CADT4RqB==eRKRABAAVTosHtpp--W7yxQGFW9f=Jr28EbJ0FigQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>
> Without re-using prepared statements or portals, extended protocol is
> always slow because it requires more messages exchanges than simple
> protocol. In pgbench case, it always sends parse, bind, describe,
> execute and sync message in each transaction even if each transaction
> involves identical statement ("SELECT 1" in your case).
>
> See the manual for the protocol details.
>
I'm well aware of how the extended protocol works, but it seems odd for a
30% increase in processing time to be the result exclusively of processing
5 messages instead of just 1 - it doesn't seem like that big a deal
(although I may be mistaken). I was imagining that there's something more
fundamental in how the protocol or PostgreSQL state is managed internally,
that would be responsible for the slowdown.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Vladimir Sitnikov | 2016-07-31 15:47:25 | Re: Slowness of extended protocol |
| Previous Message | Stephen Frost | 2016-07-31 14:59:49 | Re: pg_dumping extensions having sequences with 9.6beta3 |