3 ms·
I think it would have been even faster if they'd test with SQL Server because you can do things with SQL Server that you simply cannot do in PG such as stored p
by hungerstrike 8y ago
I think it would have been even faster if they'd test with SQL Server because you can do things with SQL Server that you simply cannot do in PG such as stored procedures that return multiple resultsets, which saves a ton of round-trips.
- zapov 8y agoYou can do even more advanced stuff in Postgres, but they've changed the rules to dissalow it since it much more faster than the the current best ones. Something about being fair to other frameworks...
- hungerstrike 8y agoCan you request multiple heterogeneous result-sets from PG now, with something that looks like a stored procedure? I'd love to see what that looks like. In SQL Server it's as easy as putting 2 SELECT statements in the same procedure.
- zapov 8y agoHere is an old post of mine about that: https://blog.dsl-platform.com/multiple-result-sets-alternatives-in-postgres-3/ https://blog.dsl-platform.com/multiple-result-sets-alternati...
- anarazel 8y ago> Can you request multiple heterogeneous result-sets from PG now, with something that looks like a stored procedure? Not prettily. You can return cursors, you can use json etc, ... But you can pipeline SQL statements. I.e. just send N SQL statements (including bind parameters etc, the protocol is the same) without waiting for results, and then process the results as they come in. If you want to avoid latency penalties that makes much more sense in my opinion than having to wrap multiple statements in a function.
- benaadams 8y agoSQLServer might be in next round https://github.com/TechEmpower/FrameworkBenchmarks/pull/3807 https://github.com/TechEmpower/FrameworkBenchmarks/pull/3807