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 22, 2022. It is now read-only.
Unless I'm mistaken, the code doesn't seem to create SQL indexes, and a quick look at the queries leaves me under the impression that they would benefit from indexes.
Any thoughts ?
The text was updated successfully, but these errors were encountered:
Hi, adding a UNIQUE constraint to a column will create a unique index behind the scenes. Same with PRIMARY KEY designations. But now that you mention the indexes, I am not sure about FOREIGN KEY columns...can you find out if they create indexes? If not, we should add them
In most real systems, an index should be created on the child key columns of each foreign key constraint. The child key index does not have to be (and usually will not be) a UNIQUE index.
Thanks! There should definitely be an improvement if indexes are added for the FKs. Good catch.
I will leave this issue open for a bit, since is a straightforward problem to tackle for people interested in contributing to Supertag. It will likely just involve adding a new migration file (named m1.mod) here with the relevant schema changes
Also the queries against pins.tag_ids don't seem to be currently optimized. By the way, I'm not sure I understood your comments around the creation of the pins table: you're mentionning using FTS5, but the code doesn't seem to actually leveraging it.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Unless I'm mistaken, the code doesn't seem to create SQL indexes, and a quick look at the queries leaves me under the impression that they would benefit from indexes.
Any thoughts ?
The text was updated successfully, but these errors were encountered: