Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Configurable caching of ephemeral prepared statements #1149

Open
CAFxX opened this issue Aug 19, 2020 · 0 comments
Open

Configurable caching of ephemeral prepared statements #1149

CAFxX opened this issue Aug 19, 2020 · 0 comments
Labels

Comments

@CAFxX
Copy link

CAFxX commented Aug 19, 2020

This is more of as a feature suggestion than anything else (I would have added it to the wiki, but it's readonly): since the driver already creates ephemeral prepared statements when executing queries with interpolateParams=false it could be interesting to allow users to opt-in to have the driver dynamically cache up to a configurable number of automatically-created prepared statements corresponding to the most frequently executed queries.

By default this cache would be off, and users could opt-in e.g. with a DSN parameter like cacheStatements=N, where N is the maximum number of prepared statements that can be in the cache. The driver internally would keep a larger (but bounded) approximate set of the most frequently executed queries, but only the top N statements would be eligible for having the corresponding prepared statement be kept in the cache. The documentation should clearly state that N is per-connection, and that therefore the total number of prepared statements on the server used by this cache can reach up to N*num_open_connections, and that therefore careful configuration is required both on the client (SetMaxOpenConns) and on the server (max_prepared_stmt_count).

The rationale for this is that in our experience many services have a (small) subset of hot queries. If the driver implemented this feature, it would transparently give significant performance benefits - as it would avoid the prepared statement roundtrip at least on the most frequently executed queries without requiring users to manually curate and maintain the list of which statements should be prepared beforehand.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants