Change to use selectin for RBACs in SubnetPool DB load strategy
To solve a performance issue when using network rbacs with thousands
of entries in the subnets, networks, and networks rbacs tables, it's
necessary to change the eager loader strategy to not create and process
a "cartesian" product of thousands of unnecessary combinatios for the
purpose of the relationship included between rbac rules and subnetpool
database model.
We don't need a many-to-many relationship here. So, we can use the
selectin eager loading to make this relationship one-to-many and create
the model with only the necessary steps, without exploding into a
thousands of rows caused by the "left outer join" cascade.
The "total" queries from this process would be divided into a series of
smaller queries with much better performance, and the resulting huge
select query will be resolved much faster without joined cascade,
representing significant performance gains.
Closes-bug: #2071374
Change-Id: I2e4fa0ffd2ad091ab6928bdf0d440b082c37def2
(cherry picked from commit 46edf255bde0603fe88b2dd9f4e482590e384382)
Reviewed: https:/ /review. opendev. org/c/openstack /neutron/ +/923496 /opendev. org/openstack/ neutron/ commit/ a73ef23e3fca625 b82d59c4e2aa10b 8d8736d78b
Committed: https:/
Submitter: "Zuul (22348)"
Branch: stable/2023.2
commit a73ef23e3fca625 b82d59c4e2aa10b 8d8736d78b
Author: Roberto Bartzen Acosta <email address hidden>
Date: Thu Jun 27 18:29:37 2024 +0000
Change to use selectin for RBACs in SubnetPool DB load strategy
To solve a performance issue when using network rbacs with thousands
of entries in the subnets, networks, and networks rbacs tables, it's
necessary to change the eager loader strategy to not create and process
a "cartesian" product of thousands of unnecessary combinatios for the
purpose of the relationship included between rbac rules and subnetpool
database model.
We don't need a many-to-many relationship here. So, we can use the
selectin eager loading to make this relationship one-to-many and create
the model with only the necessary steps, without exploding into a
thousands of rows caused by the "left outer join" cascade.
The "total" queries from this process would be divided into a series of
smaller queries with much better performance, and the resulting huge
select query will be resolved much faster without joined cascade,
representing significant performance gains.
Closes-bug: #2071374 1ab6928bdf0d440 b082c37def2 fe88b2dd9f4e482 590e384382)
Change-Id: I2e4fa0ffd2ad09
(cherry picked from commit 46edf255bde0603