> On the other hand, if our goal in life is to promote the extended
> query protocol over the simple query protocol at all costs, then I
> agree that we shouldn't optimize the simple query protocol in any way.
> Perhaps we should even post a big notice on it that says "this
> facility is deprecated and will be removed in a future version of
> PostgreSQL". But why should that be our goal? Presumably our goal is
> to put forward the best technology, not to artificially pump up one
> alternative at the expense of some other one. If the simple protocol
> is faster in certain use cases than the extended protocol, then let
> people use it. I wouldn't have noticed this optimization opportunity
> in the first place but for the fact that psql seems to use the simple
> protocol - why does it do that, if the extended protocol is
> universally better? I suspect that, as with many other things where
> we support multiple alternatives, the best alternative depends on the
> situation, and we should let users pick depending on their use case.
+1. I don't see any justfication not to enhance simple protocol case
influenced by extended protocol's relatively poor performance.
> At any rate, if you're concerned about the relative efficiency of the
> simple query protocol versus the extended protocol, it seems that the
> horse has already left the barn. I just did a quick 32-client pgbench
> -S test on a 32-core box. This is just a thirty-second run, but
> that's enough to make the point: if you're not using prepared queries,
> using the extended query protocol incurs a significant penalty - more
> than 15% on this test:
>
> [simple] tps = 246808.409932 (including connections establishing)
> [extended] tps = 205609.438247 (including connections establishing)
> [prepared] tps = 338150.881389 (including connections establishing)
Quite impressive result.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
