Open dartcafe opened 2 months ago
Some numbers see https://github.com/nextcloud/polls/issues/3679#issuecomment-2326166328:
@AndyScherzinger I think, the subqueries cause a heavy load, if any poll scans shares, ... every poll.
Additionally some indices should be created to avoid full table scans. It would be nice if someone could test the changes I will try in a PR by applying the patches. Do you think you can do that?
I can ask people to test tomorrow and will post an analysis later why the index recreation is expected to cause the problem in the first place (sorry for the teaser, currently on the phone)
Back at the PC, posted my comment as mentioned in https://github.com/nextcloud/polls/issues/3679#issuecomment-2329541569 since it is about the reasons why indexes should not be recreated except when actually needed to.
But also to comment on the statement @dartcafe
I think, the subqueries cause a heavy load, if any poll scans shares, ... every poll.
https://github.com/nextcloud/polls/issues/3679#issuecomment-2329541569 proves this hypothesis but also shows why recreating indexes also makes you not hit an index and if that takes down the system the optimized queries using indexes won't solve the issue. They are just another optimization step, also helpful but not the cause of the issue.
Index creation is another issue. But I count the priority of the runtime issue higher. So lets first solve this first.
I still have limited time (and brain) theese weeks.
Index creation is another issue. But I count the priority of the runtime issue higher. So lets first solve this first.
I disagree. The index issue blocks upgrade large scale instances completely, for the app as well as for the server (which triggers updating apps as part of the server upgrade automatically).
I still have limited time (and brain) theese weeks.
Like I said in the chat, I totally get that and am in the same position. Yet I am in the same situation for exactly this reason - I need a Polls app usable for a large scale instance meaning the ability to update without taking down the system indefinitely - which is why I disagree with the assessment in the first comment of this post.
So how can we move forward so this works for all of us and meets everyone's requirements and is not an issue for either one of us?
⚠️ This issue respects the following points: ⚠️
Describe the goal you'd like to achieve
As a poll user, I want to **enter the app without long loading times.
Describe possible solutions
No response
Additional context
There is an instance, where collecting all polls lasts verly long (something about 22 minutes).
It seems that this SQL is responsible for the huge loading time: