-
Notifications
You must be signed in to change notification settings - Fork 3
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
Remove first two unused indexes #376
Conversation
This stack of pull requests is managed by Graphite. Learn more about stacking. |
c0fb77f
to
4538890
Compare
|
||
--bun:split | ||
|
||
CREATE INDEX CONCURRENTLY IF NOT EXISTS message_pubsubTopic_idx ON public.message (pubsubTopic); |
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.
Without CONCURRENTLY, does the server start up extremely slowly?
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.
It would also take a lock of the entire table and block reads
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.
I'm having problems actually running concurrent index drops in a migration (for some reason it is trying to run the migration in a tx, which is not allowed). I might just make this non-concurrent but manually drop the index concurrently in prod first.
pkg/migrations/messages/20240419172419_remove-unused-indexes-pt-1.up.sql
Outdated
Show resolved
Hide resolved
I've manually dropped |
tl;dr
We have a bunch of gigantic Postgres indexes that are completely unused. I am dropping the first three that feel uncontroversial.
Some data
These are our current database indexes
By running this SQL, I got the list of when they were last read:
Which tells me that this index has never been used in a query.
messageindex
is used as a primary key so we can't kill it.Next up
There are three more indexes that have been read in the past, but when I re-run the query above the values don't change or change very little.
message_recvts_shouldexpire_idx
gets used extremely infrequently, as it has largely been replaced withmessage_recvts_shouldexpiretrue_idx
which gets used a lot. But I'd like to understand why the delta isn't 0.message_contenttopic_idx
is also quite infrequently read. Because it shares a prefix withmessage_ctopic_sts_id_idx
, I believe deleting it is safe and the other index could be used. But I'm also hesitant there.message_sort_idx
has basically never been used and is safe to delete.