Skip to content
This repository has been archived by the owner on Nov 11, 2024. It is now read-only.

Prepared statements #30

Open
aleclarson opened this issue Sep 12, 2022 · 0 comments
Open

Prepared statements #30

aleclarson opened this issue Sep 12, 2022 · 0 comments
Labels
enhancement New feature or request

Comments

@aleclarson
Copy link
Contributor

aleclarson commented Sep 12, 2022

https://www.postgresql.org/docs/current/sql-prepare.html

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:

const preparedQuery =
  db.select(...)
    .innerJoin(...)
    .innerJoin(...)
    .prepare('unique_name')

// Release from memory
preparedQuery.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
@aleclarson aleclarson added the enhancement New feature or request label Sep 12, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant