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
Unknown Object (File)
Tue, Nov 12, 12:51 PM
Unknown Object (File)
Oct 23 2024, 2:58 AM
Unknown Object (File)
Oct 19 2024, 4:00 PM
Unknown Object (File)
Oct 18 2024, 8:24 PM
Unknown Object (File)
Oct 15 2024, 9:28 PM
Unknown Object (File)
Oct 15 2024, 5:56 PM
Unknown Object (File)
Sep 28 2024, 12:08 PM
Unknown Object (File)
Sep 28 2024, 12:08 PM
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
Lint
Lint Not Applicable
Unit
Tests Not Applicable

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.