Comment 53 for bug 1918145

On (1) - OK, interesting observation. I will consider why the object_id index was added/what may use it. But even 1s is quite slow (vs. the 0.05s you mention... there is still a big performance crunch).

On (2) - Handwaving a bit and speaking from memory - but I think the project_id filter is used extensively in the RBAC code. Its role is to select RBACs which are applicable to the context - that being RBACs which are either global *or* which are scoped to the project(_id). Any time Neutron networks, subnets, etc. are filtered or collected, the code generally flows through this query logic which itself operates on RBACs relative to the context, which is where this "global RBAC or context/project-specific RBAC" use and thus filter against project_id comes into play. For this reason, if you query things as admin (without changing the code), you will probably not see the performance hit.

IOW, I don't think it can be removed as its use is integral to how all the Neutron code is written. This is what led to my PS which splits the logic for these two cases and does a late union of that either/or case.