-
Notifications
You must be signed in to change notification settings - Fork 4
feat(migration): create unique index on folders for parent_uuid and plain_name #882
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
base: master
Are you sure you want to change the base?
feat(migration): create unique index on folders for parent_uuid and plain_name #882
Conversation
0ae29f3 to
6c4180d
Compare
sg-gs
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Running migration @jzunigax2
|
This PR is stale because it has been open for more than 15 days with no activity. |
6c4180d to
e85fbd6
Compare
|
This PR has conflicts with master @jzunigax2, let's reconcile it (waiting this before #883) |
e85fbd6 to
20491aa
Compare
|



What
Create a new unique index
folders_parentuuid_plainname_uniqueon the folders table using (parent_uuid,plain_name) to replace the legacy
folders_plainname_parentid_keyindex.Why
1. Legacy index uses deprecated column
The current unique index folders_plainname_parentid_key uses parent_id (integer FK), while we have kept
migrating towards using parent_uuid (UUID FK) for all folder relationship operations.
-- Current (legacy)
CREATE UNIQUE INDEX folders_plainname_parentid_key
ON folders (plain_name, parent_id)
WHERE deleted = false;
-- New (aligned with application code)
CREATE UNIQUE INDEX folders_parentuuid_plainname_unique
ON folders (parent_uuid, plain_name)
WHERE deleted = false;
2. Suboptimal column order causing inefficient uniqueness checks
The legacy index has plain_name as the first column, which has low cardinality. This forces the db to possibly scan through entries before narrowing by parent.
The new index places parent_uuid first (high cardinality).
3. Application code already uses parent_uuid:
How
Migration uses CREATE INDEX CONCURRENTLY to avoid table locks: