panates / postgrejs-kysely / 37469789172

100%

main: 100%

push

github

bench: stop billing PostgreJS for a feature pg does not have

`asyncErrorHandling` defaults to on, and this dialect forwards six query
options but not that one, so the pool's setting decided - and the pool
was opened without it. Every published number was therefore measured
with PostgreJS capturing a stack per call so a rejected query points at
the caller's line, which `pg` offers no equivalent of and pays nothing
for. Both pools now pass `asyncErrorHandling: false`, including the one
`describeScenarios()` opens, and the setting is written into the results
file as `clientConfig` so the document states it from the run's own
record.

Verified on a live connection rather than assumed: `pool.config` and the
acquired connection's `config` both read false.

It is off because the comparison should not cover it, not because it
moves the answer - reported from the drizzle round as about 3% on the
one scenario with several calls in flight and nothing elsewhere.

Re-measured, and three things differ from the last run at once: postgrejs
3.12.1 -> 3.13.0, pg 8.23.0 -> 8.23.1, and this flag. So no row's
movement can be attributed to any of them, and this commit does not try.
What the run says on its own terms: postgrejs still wins every scenario,
two write rows allocate far less than they did (`insert a 100k int4[]`
993 KB against 1.7 MB, `insert a 4MB bytea` 2.7 MB against 4.1 MB), and
`insert 500 rows` is no longer distinguishable on the clock at 38 of 61
pairs, where it was 55 of 61. The generated prose follows all three
without anyone editing a sentence.

90 of 91 branches covered (98.9%)

Branch coverage included in aggregate %.

653 of 653 relevant lines covered (100.0%)

37.81 hits per line