We are observing a 10-30% regression in aggregate SQL execution time in v1.2.3 in some cases.

[kitsunde]

I haven't devised a test for this yet because I'm not sure what to test exactly, but we monitor our SQL execution times. Specifically, with prometheus_exporter we collect durations of SQL execution on each endpoint by hooking into PG::Connection in Rails:

MethodProfiler.patch(PG::Connection, [
  :exec, :async_exec, :exec_prepared, :send_query_prepared, :query
], :sql)

When we upgraded from 1.2.2 to 1.2.3 we observe the following:

When we reverted the change the reverse happens:

These are the execution times of 30-50 queries in each graph. Looking through the changes in 1.2.3 I'm assuming the time isn't actually spent on SQL executing in PG but rather overhead in the library itself.

We've never faced the issue with segmentation faults that the 1.2.3 release is supposed to fix despite being on ruby 2.7.x for months with a fair amount of traffic.

[larskanis]

@kitsunde Thank you for the detailed report! And sorry for the long delay!

The new pg version 1.3.0 changes a lot regarding the handling of the socket IO. It would be very interesting how your results are performance-wise!

[larskanis]

pg-1.3.0 has a new install switch which should improve the query performance a little bit, but it is not enabled per default:

gem inst pg -- --disable-gvl-unlock

or through bundler:

bundle config build.pg --disable-gvl-unlock

See here in the History.rdoc.