Skip to content
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

Merged
merged 10 commits into from
May 10, 2024
Merged

Conversation

neekolas
Copy link
Collaborator

@neekolas neekolas commented Apr 19, 2024

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

CleanShot 2024-04-19 at 11.06.37@2x.png

By running this SQL, I got the list of when they were last read:

SELECT relname , indexrelname , idx_scan , idx_tup_read , idx_tup_fetch
FROM pg_stat_user_indexes
WHERE schemaname = 'public' and relname = 'message';

Which tells me that this index has never been used in a query.

CleanShot 2024-04-19 at 11.08.50@2x.png

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 with message_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 with message_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.

Copy link
Collaborator Author

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @neekolas and the rest of your teammates on Graphite Graphite

@neekolas neekolas marked this pull request as ready for review April 19, 2024 18:19
@neekolas neekolas force-pushed the 04-19-remove_first_two_unused_indexes branch from c0fb77f to 4538890 Compare April 19, 2024 19:31

--bun:split

CREATE INDEX CONCURRENTLY IF NOT EXISTS message_pubsubTopic_idx ON public.message (pubsubTopic);
Copy link
Contributor

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?

Copy link
Collaborator Author

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

Copy link
Collaborator Author

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.

@neekolas
Copy link
Collaborator Author

neekolas commented Apr 22, 2024

I've manually dropped message_pubsubTopic_idx, message_recvts_shouldexpire_idx, and message_sort_idx concurrently in prod. Will do the same in dev and then update this PR to include all the drops.

@neekolas neekolas merged commit a544937 into main May 10, 2024
4 checks passed
@neekolas neekolas deleted the 04-19-remove_first_two_unused_indexes branch May 10, 2024 20:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants