Comment 10 for bug 2037107
Revision history for this message
| Rodolfo Alonso (rodolfo-alonso-hernandez) wrote | #10 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0f7b58d
(Get the code!)
Hello Max:
Yes, any RBAC resource is still returning a query result with a very low cardinality. But the main problem (not the only one of course) solved in [1] was the cardinality of the inner query. From your example: [2]. This query was returning millions of results with a big amount of projects and RBACs, all defined from the same project. Please check [3] commit message:
"""
This SQL result has a very low cardinality; that means there are many
duplicated registers. For example, with 10 external network, 1000
projects and 2500 RBAC rules, this query returns 1.4 million rows.
Instead if a "GROUP BY resource_id" (in this case network_id) clause is
added, the number of rows is reduced to 10 (considering this project
has a RBAC per network).
"""
This topic should be handled in other LP bug. Let's focus the current one in the subnet network RBAC optimization.
Regards.
[1]https:/
[2]https:/
[3]https:/