-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
state_groups_state uses a large sequential scan #5064
Comments
Thanks! We'll take a look at that. |
I'm really surprised that this makes a difference. Obviously I don't have identical data, but equivalent queries are approximately instant. The query plan should look like:
@grinapo: could you confirm a few things for me:
|
Dropping the index now gives:
|
I am at a loss to explain why postgres has decided to seq scan rather than index scan :/ |
Here's an
|
Forcing
|
And the specific timings with the index, again:
|
Without the index the specific timings:
|
Not exactly the 60second version, but longer than 20ms:
|
It seems the stats sample has to be raised. Maybe this applies to other tables.... 🙄 |
I just caught a nearly identical query running for a long period, simultaneous with synapse 1.0 memory use exploding by a factor of 4 or so: state(state_group) AS ( VALUES(3916371::bigint) UNION ALL SELECT prev_state_group FROM state_group_edges e, state s WHERE s.state_group = e.state_group ) SELECT DISTINCT type, state_key, last_value(event_id) OVER ( PARTITION BY type, state_key ORDER BY state_group ASC ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING ) AS event_id FROM state_groups_state WHERE state_group IN ( SELECT state_group FROM state ) AND ((type = 'm.room.history_visibility' AND state_key = '') OR (type = 'm.room.member')); However, the query plan does not seem to involve any sequential scans:
|
Yup, I think the postgres statistics are wrong for some people using the default postgres sampling sizes. This is more of a DB ops problem than an app problem, so I don't really know what Synapse can do about it. The options as far as I can see are:
|
I was affected by very similar symptoms preventing me from logging in at all. I created the index proposed in the opening post and I can now login. Before:
with the index:
|
I still have a problem with WITH RECURSIVE state(state_group) AS ( VALUES(17434::bigint) UNION ALL SELECT prev_state_group FROM state_group_edges e, state s WHERE s.state_group = e.state_group ) SELEC
T DISTINCT ON (type, state_key) type, state_key, event_id FROM state_groups_state WHERE state_group IN ( SELECT state_group FROM state ) AND ((type = 'm.room.member')) ORDER BY type, state_key, st
ate_group DESC;
Postgresql overestimates the number of rows in the CTE (here, only two).
|
I had more luck with this patch: diff --git a/synapse/storage/databases/state/bg_updates.py b/synapse/storage/databases/state/bg_updates.py
index 139085b67..2b426b660 100644
--- a/synapse/storage/databases/state/bg_updates.py
+++ b/synapse/storage/databases/state/bg_updates.py
@@ -88,6 +88,7 @@ class StateGroupBackgroundUpdateStore(SQLBaseStore):
# Temporarily disable sequential scans in this transaction. This is
# a temporary hack until we can add the right indices in
txn.execute("SET LOCAL enable_seqscan=off")
+ txn.execute("SET LOCAL enable_bitmapscan=off")
# The below query walks the state_group tree so that the "state"
# table includes all state_groups in the tree. It then joins |
I think what is happening here is that if the server is in very large rooms the statistics collector ends up thinking that there are few distinct state groups, and so when we come to query e.g. 50 of them the query planner ends up thinking that "50 state groups is a majority of the table, and so we may as well scan the entire table". If people who run into this can report what SELECT attname, inherited, n_distinct, correlation
FROM pg_stats
WHERE tablename = 'state_groups_state'; It should either be very large, or negative. Two solutions here are:
|
Actually, I'm not sure that is true. It may be true for unique indices, and creating the index likely updates the |
First of all, it looks like I'm not affected by slowness anymore, even dropping the patch mentioned above. About your query, here are my numbers:
|
#10359 made a night/day difference to my disk IO and CPU usage. Seems like that fixed the problem for me. |
A note for others finding this problem: somebody else had ended up (via a mistake with (likewise, a loop in state_group_edges would be a massive problem) |
Description
I have caught a query which runs several times for room history, recursively, and therefore take a significant amount of time (tens of minutes) to scroll up.
And the query can be speeded up by
Without it the planner say:
And with it it's
which is 175 times faster. ;-)
Version information
If not matrix.org: matrix.grin.hu
Version: 0.99.2
Install method: debian pkg + workers
Platform: debian linux (testing)
The text was updated successfully, but these errors were encountered: