pg: prepare+cache query statements - #115
Open
phlip9 wants to merge 4 commits into
Open
Conversation
So I can `POSTGRES_ENDPOINT='postgresql://%2Frun%2Fuser%2F1000' cargo test` against my user-local, socket-activated dev postgres.
Without this change, we would re-parse and re-plan each query, potentially multiple times per request (!). Instead, maintain a small prepared statement cache per connection. We'll lazily prepare a query statement the first time we execute it, then use the prepared statement thereafter. This change reduces latency by ~20-60% on my small benchmark suite, but is particularly impactful on batch conditional updates, where we were previously re-parsing and re-planning the put query for each item in the batch. This change improved throughput there by ~1.5x (~4.8k/s -> 12.3k/s).
|
I've assigned @tankyleo as a reviewer! |
Author
|
Oops, looks like the new |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Without this change, we would re-parse and re-plan each query, potentially multiple times per request (!). For simple queries, this appears to add ~100-200 us overhead. More for more complex queries.
Instead, maintain a small prepared statement cache per connection. We'll lazily prepare a query statement the first time we execute it, then use the prepared statement thereafter.
This change reduces latency by ~20-60% on my small benchmark suite, but is particularly impactful on batch conditional updates, where we were previously re-parsing and re-planning the
putquery for each item in the batch. This change improved throughput there by ~2.5x (~4.8k/s -> 12.3k/s).Using const
&'static strqueries is really more a stylistic preference on my part. I think it adds a nice roadblock to prevent people from accidentally addinglet stmt = format!("..", untrusted_user_input)-> SQL injection.Migrations and other admin queries are still uncached, since they're usually only executed once.