> 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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers