Query performance flag.count getUserFlagFlaggingCount

Created on 13 April 2018, about 7 years ago
Updated 19 February 2025, about 2 months ago

Problem/Motivation

The flagging table can be slow to access for particularly large datasets.

Proposed resolution

Create a StorageSchema handler to change the row format of the flagging table and add an index to be equivalent to the following SQL.

ALTER TABLE  `flagging` ROW_FORMAT = DYNAMIC
ALTER TABLE  `flagging` ADD INDEX  `flag_id__uid__session_id` (  `flag_id` ,  `uid` ,  `session_id` )

Remaining tasks

Create patch.

User interface changes

None.

API changes

None.

Data model changes

None.

Original issue

We're using the getUserFlagFlagginCount method on the flag.count service. We've got a massive `flagging` table of +300.000 rows and the method is running massively slow. We've been able to fix this by creating a new table index:

ALTER TABLE  `flagging` ROW_FORMAT = DYNAMIC
ALTER TABLE  `flagging` ADD INDEX  `flag_id__uid__session_id` (  `flag_id` ,  `uid` ,  `session_id` )

This gave us a massive database performance boost. I've not been able to create a patch for this as we speak, though I just made this into a issue for documentation and patching purposes.

๐Ÿ“Œ Task
Status

Needs work

Version

4.0

Component

Flag core

Created by

๐Ÿ‡ณ๐Ÿ‡ฑNetherlands aken.niels@gmail.com

Live updates comments and jobs are added and updated live.
  • Needs reroll

    The patch will have to be re-rolled with new suggestions/changes described in the comments in the issue.

Sign in to follow issues

Merge Requests

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

Production build 0.71.5 2024