You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Following up on #290, I would like to encode all bind params as binary. Partly because it might help avoid issues like #267 entirely to use a single encoding format, but also I ran a quick benchmark and, unless I've made a mistake in that benchmark, it's faster by a surprising margin and allocates significantly less on the heap (zero bytes allocated for String and UUID parameters).
In fairness, this benchmark only measures the time spent encoding the data into a slice. Presumably, we spend a trivial amount of time encoding a handful of query params compared to the time spent in TLS, the kernel segments of the network stack, and decoding an unbounded quantity of result values.
The maximum number of bind parameters that Postgres supports in a single query is 65535, so I don't imagine this is likely to have a notable impact on performance. The only way to know for sure, though, is to benchmark holistically.
The text was updated successfully, but these errors were encountered:
Following up on #290, I would like to encode all bind params as binary. Partly because it might help avoid issues like #267 entirely to use a single encoding format, but also I ran a quick benchmark and, unless I've made a mistake in that benchmark, it's faster by a surprising margin and allocates significantly less on the heap (zero bytes allocated for
String
andUUID
parameters).benchmark code
benchmark results
additional notes on relative performance
In fairness, this benchmark only measures the time spent encoding the data into a slice. Presumably, we spend a trivial amount of time encoding a handful of query params compared to the time spent in TLS, the kernel segments of the network stack, and decoding an unbounded quantity of result values.
The maximum number of bind parameters that Postgres supports in a single query is 65535, so I don't imagine this is likely to have a notable impact on performance. The only way to know for sure, though, is to benchmark holistically.
The text was updated successfully, but these errors were encountered: