-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Conversation
Signed-off-by: Olivier Wilkinson (reivilibre) <olivier@librepush.net>
Old collection is not included in this commit Signed-off-by: Olivier Wilkinson (reivilibre) <olivier@librepush.net>
Signed-off-by: Olivier Wilkinson (reivilibre) <olivier@librepush.net>
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 think mainly I'm a bit confused about the expected life cycle here? It feels like we're inserting dirty rows into the table and then updating them when we encounter them? Can you outline how this is expected to work please :)
room & user statistics. | ||
""" | ||
_run_create_generic("room", cursor, database_engine) | ||
_run_create_generic("user", cursor, database_engine) |
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 think it'd be a lot clearer to just have two schema files *.sql.postges
and *.sql.sqlite
and list the create index clauses. This code generation is a lot longer than the eight lines of sql it generates :)
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 be – but afaict there isn't a mechanism to do so.
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.
Oh booo, its only implemented for full schemas and not deltas.
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.
@erikjohnston With #5911, this should be resolved, I hope?
Co-Authored-By: Erik Johnston <erik@matrix.org>
Co-Authored-By: Erik Johnston <erik@matrix.org>
Signed-off-by: Olivier Wilkinson (reivilibre) <olivier@librepush.net>
Signed-off-by: Olivier Wilkinson (reivilibre) <olivier@librepush.net>
Signed-off-by: Olivier Wilkinson (reivilibre) <olivier@librepush.net>
Signed-off-by: Olivier Wilkinson (reivilibre) <olivier@librepush.net>
Signed-off-by: Olivier Wilkinson (reivilibre) <olivier@librepush.net>
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.
As per IRL let's change the tables slightly so we can just do upserts to simplify the logic.
This obviates the need for old collection, but comes at the minor cost of not being able to track historical stats or per-slice fields until after the statistics regenerator is finished. Signed-off-by: Olivier Wilkinson (reivilibre) <olivier@librepush.net>
Signed-off-by: Olivier Wilkinson (reivilibre) <olivier@librepush.net>
Signed-off-by: Olivier Wilkinson (reivilibre) <olivier@librepush.net>
Signed-off-by: Olivier Wilkinson (reivilibre) <olivier@librepush.net>
Signed-off-by: Olivier Wilkinson (reivilibre) <olivier@librepush.net>
1ce7b71
to
1ecd1a6
Compare
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.
Looks good. Mostly some code cleanup, but a few niggles:
- Can we use timestamps in milliseconds please, which is what the rest of the code base uses (yes, its space inefficient for this but consistency ftw).
- Can we keep the documentation until the last PR please, in case it changes and we forget about it.
- We'll need to figure out the background update TODO before this lands on develop, but that can wait until future PR
synapse/storage/stats.py
Outdated
|
||
additive_relatives = { | ||
key: fields.get(key, 0) | ||
for key in abs_field_names |
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.
Why are we looking at absolute ABSOLUTE_STATS_FIELDS
to figure out which ones are additive?
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.
Added a comment which should hopefully clarify this – let me know if not.
c44a8cf
to
5043ef8
Compare
Co-Authored-By: Erik Johnston <erik@matrix.org>
Signed-off-by: Olivier Wilkinson (reivilibre) <olivier@librepush.net>
Signed-off-by: Olivier Wilkinson (reivilibre) <olivier@librepush.net>
Should not be too much of a performance concern as this code won't be hit on Postgres, which large deployments should be using. Signed-off-by: Olivier Wilkinson (reivilibre) <olivier@librepush.net>
Signed-off-by: Olivier Wilkinson (reivilibre) <olivier@librepush.net>
Signed-off-by: Olivier Wilkinson (reivilibre) <olivier@librepush.net>
Signed-off-by: Olivier Wilkinson (reivilibre) <olivier@librepush.net>
Signed-off-by: Olivier Wilkinson (reivilibre) <olivier@librepush.net>
Signed-off-by: Olivier Wilkinson (reivilibre) <olivier@librepush.net>
Signed-off-by: Olivier Wilkinson (reivilibre) <olivier@librepush.net>
`absolute_fields` being None shouldn't preclude completion of a current stats row. Signed-off-by: Olivier Wilkinson (reivilibre) <olivier@librepush.net>
Signed-off-by: Olivier Wilkinson (reivilibre) <olivier@librepush.net>
Co-Authored-By: Erik Johnston <erik@matrix.org>
Signed-off-by: Olivier Wilkinson (reivilibre) <olivier@librepush.net>
Signed-off-by: Olivier Wilkinson (reivilibre) olivier@librepush.net
This PR is the second in a series of PRs replacing #5847, which does the following:
These PRs will be merged into an intermediate branch (#5879) as some features may be broken if not all the PRs are applied at once.