Bug 2053504 - Need to add index to tracking_flags_values table for better performance from search - #2665
Bug 2053504 - Need to add index to tracking_flags_values table for better performance from search#2665dklawren wants to merge 2 commits into
Conversation
There was a problem hiding this comment.
Pull request overview
Adds a new database index to improve query performance when looking up tracking flag values (notably impacting /bzapi/bug and REST search paths that touch tracking_flags_values).
Changes:
- Add a non-unique index on
tracking_flags_values.tracking_flag_id. - Update the TrackingFlags extension’s abstract schema to declare the new index.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
…tter performance from /bzapi/bug and REST search
dklawren
changed the title
dklawren
changed the title
| INDEXES => [ | ||
| tracking_flags_values_idx => | ||
| {FIELDS => ['tracking_flag_id', 'value'], TYPE => 'UNIQUE',}, | ||
| tracking_flags_values_tracking_flag_id_idx => ['tracking_flag_id'], |
There was a problem hiding this comment.
Looking at the plan from the bug, the filter passes all 7,014 rows it scans, and Query Insights has it averaging 3,499 rows returned out of a ~7,000 row table. At that selectivity MySQL will keep picking the table scan over a range scan, so I don't think this index will change the plan. Have you been able to try it on a copy of prod?
|
|
||
| $dbh->bz_add_index('tracking_flags_values', | ||
| 'tracking_flags_values_tracking_flag_id_idx', | ||
| [qw(tracking_flag_id)]); |
There was a problem hiding this comment.
The other thing that stands out in the screenshot from the bug is 2.4M calls at 9ms - preload_all_the_things re-runs this on every Flag->match, and get_all only caches in request_cache. Since the values change rarely, would caching them with memcached get us more than an index will?
No description provided.