You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 11, 2024. It is now read-only.
Prepared statements potentially have the largest performance advantage when a single session is being used to execute a large number of similar statements. The performance difference will be particularly significant if the statements are complex to plan or rewrite, e.g., if the query involves a join of many tables or requires the application of several rules. If the statement is relatively simple to plan and rewrite but relatively expensive to execute, the performance advantage of prepared statements will be less noticeable.
The API would look like this:
constpreparedQuery=db.select(...).innerJoin(...).innerJoin(...).prepare('unique_name')// Release from memorypreparedQuery.dealloc()
Note that two separate queries cannot share the same name.
Ideas 🤔
We could generate a hash that allows automatic naming of prepared statements based on the query.
We could inject a LRU cache if enabled within tusken.config.ts
The text was updated successfully, but these errors were encountered:
https://www.postgresql.org/docs/current/sql-prepare.html
The API would look like this:
Note that two separate queries cannot share the same name.
Ideas 🤔
tusken.config.ts
The text was updated successfully, but these errors were encountered: