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

Idea: Statement Caching #496

Open
tpolecat opened this issue Jun 4, 2021 · 2 comments
Open

Idea: Statement Caching #496

tpolecat opened this issue Jun 4, 2021 · 2 comments

Comments

@tpolecat
Copy link
Member

tpolecat commented Jun 4, 2021

Skunk closes prepared statements after use, which ensures that sessions don't build up an unbounded number of open statements on the server. This is good in principle, but it means that we have to do a Parse exchange for every prepared statement, even if an identical one was previously prepared on the same Session.

An alternative way to do this would be to have an LRU cache from Statement to StatementId on each Session.

  • Parse checks the cache first and if it's there we have no need to do further work.
  • If the statement is not in the cache, do the Parse exchange and insert into the cache on success.

On both access and insert there may be cache evictions, so each Session needs to track this set as well.

  • On return to the pool all pending evictions are processed asynchronously (i.e., we do a bunch of Close exchanges). This means a Session returning to the pool may be unavailable for immediate use. We can pipeline these messages, which should be fast.

A consequence here is that .prepare can now return an F[PreparedCommand[...]] rather than a Resource[F, PreparedCommand[...]] (analogously for queries). This seems like a usability improvement to me but it will break everyone's code. As a first step we could just do Resource.eval to keep the API the same.

Note that the Describe cache is per pool so we don't want to roll it into the Parse cache, which is per session. If we did this we would end up running Describe exchanges for statements we already know are valid.

@tpolecat
Copy link
Member Author

tpolecat commented Jun 4, 2021

I should add that this really means we need to redo the session pool, which is overly complicated at the moment.

@fdietze
Copy link
Contributor

fdietze commented Jul 13, 2022

How about ditching the session pool of skunk entirely and refer to dedicated solutions like https://www.pgbouncer.org/ instead?

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

No branches or pull requests

2 participants