Page MenuHomePhabricator

When building audit queries, prefilter possible "authorPHID" values
ClosedPublic

Authored by epriestley on Feb 7 2019, 7:54 PM.
Tags
None
Referenced Files
F19507090: D20129.diff
Fri, Jan 9, 5:15 PM
F19502688: D20129.diff
Thu, Jan 8, 6:22 PM
F19074665: D20129.diff
Dec 1 2025, 6:17 AM
F19074649: D20129.diff
Dec 1 2025, 6:15 AM
F19074634: D20129.diff
Dec 1 2025, 6:13 AM
F19068396: D20129.id.diff
Nov 30 2025, 12:02 PM
F19059728: D20129.diff
Nov 29 2025, 6:42 AM
F18982325: D20129.diff
Nov 17 2025, 6:37 AM
Subscribers
None

Details

Summary

Ref T13244. See PHI1057. Currently, if you're a member of a lot of projects/packages, you can end up with a very large commit.authorPHID IN (...) clause in part of the "Active Audits" query, since your alice token in "Responsible Users: alice" expands into every package and project you can audit on behalf of.

It's impossible for a commit to be authored by anything but a user, and evidence in PHI1057 suggests this giant IN (...) list can prevent MySQL from making effective utilization of the <authorPHID, auditStatus, ...> key on the table.

Prefilter the list of PHIDs to only PHIDs which can possibly author a commit.

(We'll also eventually need to convert the authorPHIDs into identityPHIDs anyway, for T12164, and this moves us slightly toward that.)

Test Plan

Loaded "Active Audits" before and after change, saw a more streamlined and sensible authorPHID IN (...) clause afterwards.

Diff Detail

Repository
rP Phabricator
Branch
audit4
Lint
Lint Passed
Unit
Tests Passed
Build Status
Buildable 21886
Build 29881: Run Core Tests
Build 29880: arc lint + arc unit

Event Timeline

It's also possible we could benefit from doing this in Differential, which builds a similar query, but I'll wait until we confirm that this was a good idea first.

This revision is now accepted and ready to land.Feb 7 2019, 11:24 PM
This revision was automatically updated to reflect the committed changes.