workload: fix performance regresion from accessing query execution mode #102193
Conversation
sync.RWMutex RLock() became a hot path for essentially a read-only value. The execution mode of a pool and query doesn't change after program initialization. Release note: None
|
This change is |
There was a problem hiding this comment.
I am doing another full run as a sanity check.
Reviewable status:
complete! 1 of 0 LGTMs obtained (waiting on @smg260)
There was a problem hiding this comment.
Thank you. I'm tempted to make the pgx logger's presence conditional behind yet-another-connection-flag, but am not sure the juice is worth the squeeze to do that vs just removing it outright atm since I've never seen any actual log output flow through the logger or tracer interface. LMK.
Reviewable status:
Let's leave that for a follow-up story. I would also like to add a prometheus exporter (e.g., [1]) to get more insights into the connection pool. Both changes seem trivial but they need to take performance into consideration. |
|
First run looks good modulo a blip ~13:15,
Second run should be finishing up: https://grafana.testeng.crdb.io/d/I2_Fu704k/kv95?orgId=1&from=now-1h&to=now&viewPanel=4 Please update the commit to mention that it |
|
bors r+ |
|
Build failed (retrying...): |
|
This PR needs bors r- |
|
Canceled. |
In benchmarking workloads, pgx v5's tracelog incurs too much CPU overhead and GC pressure and wasn't being used. Release note: None Epic: none
srosenberg
force-pushed
the
workload-fix-method
branch
from
5273fe3 to
f13f93a
Compare
Thanks @yuzefovich and sorry! I should have verified CI passed. |
|
bors r+ |
|
Build succeeded: |
|
Thank you, @yuzefovich ! |
sync.RWMutex RLock() became a hot path for essentially a read-only value. The
execution mode of a pool and query doesn't change after program initialization.
Release note: None
Fixes: #101494