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

SQLite: Cache prepared statements behind sql.exec(). #2970

Open
wants to merge 5 commits into
base: main
Choose a base branch
from

Conversation

kentonv
Copy link
Member

@kentonv kentonv commented Oct 22, 2024

sql.exec() currently parses the query every time it is invoked. This change makes it so that we retain some number of prepared statements in a cache and reuse them, keyed by the query text. Since query strings are likely commonly internalized strings, cache lookups should be O(1) most of the time, as internalized strings compare equal by identity without the need to compare content.

…ltiple statements.

`prepare()` does not allow you to pass code that contains multiple statements (separated by semicolons). Extending it to allow this isn't straightforward, because later statements in the block might not be possible to parse if earlier statements haven't yet executed. For example, the first statement might create a table, and the next statement might insert into it. If you try to parse each statement before executing any of them, SQLite will throw an error on the second statement, because the table it's trying to insert into doesn't exist.

To support a multi-statement prepare, we must change the contract such that the whole thing is parsed lazily, on the first actual execution.

This is needed in order to support caching of prepared statements behind `exec()`, since `exec()` supports passing multiple statements at once.
This API is deprecated and won't be made public, so let's simplify the implementation to minimize maintenance burden.

This commit also changes `exec()` to take `JsString` instead of `kj::String` because caching will be keyed by the JS string handle, so that's what prepared statements need to hold onto.
…chedColumnNames

Will need to be here so it can be kept in the statement cache.
@kentonv kentonv force-pushed the kenton/sqlite-statement-cache-3 branch from abdd91a to ff99401 Compare October 22, 2024 04:04
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

Successfully merging this pull request may close these issues.

1 participant