3 ms·
> Thanks for the numbers. Can you run it for -M extended as well? That would be the case when using unnamed prepared statement. Those are worse, due to the inc
by anarazel 7y ago
> Thanks for the numbers. Can you run it for -M extended as well? That would be the case when using unnamed prepared statement.
Those are worse, due to the increased number of protocol messages (parse/bind/execute vs exec).
tps = 491218.039129 (excluding connections establishing)
> that slight overhead is more than acceptable IMO, especially when compared to MSSQL.
I wouldn't call a 2x performance difference slight... That's also with a lot of context switching overhead - if you have a client using pipelined execution, the difference also gets bigger.
- throwdbaaway 7y agoGood point about the "slight" wording, though I don't necessary agree that it can get much worse than 2x, with actual workload that: - could be more I/O bound than when just doing PK lookups with pgbench - could be getting a wrong plan from the query plan cache if named prepared statement is used