On Tue, Aug 9, 2016 at 4:50 AM, Vladimir Sitnikov <sitnikov.vladi...@gmail.com> wrote: > I've tried pgbench -M prepared, and it is way faster than pgbench -M simple.
That's true, but it's also testing something completely different from what Shay is concerned about. -M prepared creates a prepared statement once, and then executes it many times. That is, as you say, faster. But what Shay is concerned about is the case where you are using the extended query protocol to send out-of-line parameters but for some reason you can't use prepared statements, for example because the queries are dynamically generated and you have to keep sending a different query text every time. That case is analogous to -M extended, not -M prepared. And -M extended is well-known to be SLOWER than -M simple. Here's a quick test on my laptop demonstrating this: [rhaas ~]$ pgbench -M simple -S -T 10 starting vacuum...end. transaction type: <builtin: select only> scaling factor: 1 query mode: simple number of clients: 1 number of threads: 1 duration: 10 s number of transactions actually processed: 119244 latency average: 0.084 ms tps = 11919.440321 (including connections establishing) tps = 11923.229139 (excluding connections establishing) [rhaas ~]$ pgbench -M prepared -S -T 10 starting vacuum...end. transaction type: <builtin: select only> scaling factor: 1 query mode: prepared number of clients: 1 number of threads: 1 duration: 10 s number of transactions actually processed: 192100 latency average: 0.052 ms tps = 19210.341944 (including connections establishing) tps = 19214.820999 (excluding connections establishing) [rhaas ~]$ pgbench -M extended -S -T 10 starting vacuum...end. transaction type: <builtin: select only> scaling factor: 1 query mode: extended number of clients: 1 number of threads: 1 duration: 10 s number of transactions actually processed: 104275 latency average: 0.096 ms tps = 10425.510813 (including connections establishing) tps = 10427.725239 (excluding connections establishing) Shay is not worried about the people who are getting 19.2k TPS instead of 11.9k TPS. Those people are already happy. He is worried about the people who are getting 10.4k TPS instead of 11.9k TPS. People who can't use prepared statements because their query text varies - and I have personally written multiple web applications that have exactly that profile - suffer a big penalty if they choose to use the extended query protocol to pass parameters. Here, it's about a 13% performance loss. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers