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

Speed of deleting data from the users_who_share_private_rooms table #18023

Open
kosmos opened this issue Dec 10, 2024 · 0 comments
Open

Speed of deleting data from the users_who_share_private_rooms table #18023

kosmos opened this issue Dec 10, 2024 · 0 comments

Comments

@kosmos
Copy link

kosmos commented Dec 10, 2024

We encountered a problem with the performance of deleting records from the users_who_share_private_rooms table. The problem occurs when executing the following code:

https://github.com/element-hq/synapse/blob/develop/synapse/storage/databases/main/user_directory.py#L960

The first deletion is fast, but the second one has a problem under certain conditions. If the home server has rooms with a large number of users (for example, tens of thousands), then when a user is deleted, 2*n^2 records are deleted from this table.

The first deletion (https://github.com/element-hq/synapse/blob/develop/synapse/storage/databases/main/user_directory.py#L955) is fast and does not cause problems, but the second deletion, in which we search by other_user_id causes problems.

In this regard, the question came up: why exactly do we create a btree index for this field?

CREATE INDEX users_who_share_private_rooms_o_idx ON users_who_share_private_rooms USING btree (other_user_id);

Wouldn't this index be more optimal if it were hash?

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

No branches or pull requests

1 participant