-
Notifications
You must be signed in to change notification settings - Fork 137
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
Policies for removing prepared statements from the cache #282
Comments
@bikeshedder I think the flexibility to define a Cache Replacement Policy for a given Pool makes a lot of sense, especially if we can define things like the max number of queries in a cache and the max size of a cache, such as can be configured using the Postgres JDBC , i.e. That being said, I also think it would be a good idea to put a huge warning sign around |
It would be nice if there was a way to limit the amount of queries inside the statement cache so that it becomes a feasible option for use with query builders.
There are various policies for evicting items from a cache:
Two policies seam like a good fit for the statement cache:
I was also thinking about adding a second parameter to
prepare_cached
making it a bit more obvious what's actually happening and giving the user a way to fine tune the cache eviction policies:As cache eviction is not necessarily cheap I think it makes sense to only run it when returning the connection to the pool and/or if manually triggered by the user. e.g.
StatementCache.clean()
Do we even need this? Or does
prepare_cached
just need a huge warning sign explaining why you should not use it for any kind of dynamic or one-time queries?The text was updated successfully, but these errors were encountered: