Manage finite SQL resources better #150
Labels
No labels
admin tools
api
bug
documentation
duplicate
enhancement
feature
help wanted
in progress
internals
invalid
packaging
question
testing
trivial
wontfix
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: MensBeam/Arsse#150
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
While we already have problems using too much memory (see #134), an even more significant problem is the finite resources available for constructing complex SQL queries.
There are two such resources to be concerned with: the maximum number of parameter markers, and the maximum length of a query.
The first was already identified as a problem for updating very large feeds (see #71), but as criteria for article selection become more numerous and complex, SQLite's limit of 999 parameters quickly appears small.
One solution is to embed values in
IN()
clauses andLIKE
matches into the query, but this must be balanced against SQLite's 1M-byte query length limit (MySQL and PostgreSQL also have limits, but they are significantly larger). Integers should not be problematic, but strings could hypothetically be quite large.It would probably be sufficient to embed sets larger than five elements, while still parameterizing strings longer than 255 bytes in embedded sets.