- cross-posted to:
- lemmyperformance@lemmy.ml
- cross-posted to:
- lemmyperformance@lemmy.ml
Requirements
- [X] Is this a bug report? For questions or discussions use https://lemmy.ml/c/lemmy_support
- [X] Did you check to see if this issue already exists?
- [X] Is this only a single bug? Do not put multiple bugs in one issue.
- [X] Is this a backend issue? Use the lemmy-ui repo for UI / frontend issues.
Summary
The next best performance improvement, can come from going through every table trigger, seeing anything that’s more complicated than a simple increment / decrement (especially those that require functions), and moving them to periodic scheduled tasks.
These are a performance concern because all SQL triggers are synchronous.
Things like community, site and person aggregates, comment counts, user counts, etc do not need to be immediately live.
Context #3188
Steps to Reproduce
See above
Technical Details
See above
Version
main
Lemmy Instance URL
main
Originally posted by dessalines in #3528
You must log in or register to comment.
I would intuitively say that most of the reason for the slow response is not the triggers but rather the inline acrivity sending #3493. The reason is that the database update lock only single rows and are thus perfectly serializable. Basically your vote only has to wait for other votes on the same exact post/comment, so if the vote count changes by 2 when you press the button it only had to wait for one other vote that each should take less than 10ms to process for the database.
I don’t have good numbers though so I might be wrong. You can track these timings by enabling the pg_stat_statements.track=‘all’ option.
Edit: I have actually not looked at all at the non-simple-increment-decrement triggers at all, possibly disregard the above depending on when exactly those trigger.