Comment 5 for bug 2037107

Hi,

for the network model the lazy=joined with rbac_entries makes sense because its a 1:N to mapping.
But for subnets it makes no sense to me (N:M mapping). For example:
with lazy="joined"
 => the results will be multiplied(subnets X networkrbacs)
 => 13 subnets X 1270 networkrbacs => ~16000 result rows (in our prod env we currently have 2600rbacs and 20 subnets)
With lazy="subquery"
 => we fetch the 13 subnets and with a seperate query the 1270 rbacs
 => ~1283 rows

And it´s not only that the fip/port creation is slow in this network, just the network show/subnet list takes ~5 seconds (prod env).

The problem is definitely not our database.
We see no slow queries in the db (executed by hand 0.01sec to get the response)
We traced the problem down to the OVO processing(sqlalchemy read rows...)
=> Pls have a look at comment #1 in this thread at the neutron profiling from our prod env (2600rbacs and 20 subnets)
ncalls cumtime
1 14.418 /usr/local/lib/python3.10/site-packages/neutron/db/ipam_backend_mixin.py:677(_ipam_get_subnets)
1 14.418 /usr/local/lib/python3.10/site-packages/neutron/objects/subnet.py:320(find_candidate_subnets)
46324 6.222 /usr/local/lib/python3.10/site-packages/pymysql/connections.py:1266(_read_rowdata_packet)
1 7.627 /usr/local/lib/python3.10/site-packages/sqlalchemy/orm/query.py:2889(_iter)
1 7.627 /usr/local/lib/python3.10/site-packages/sqlalchemy/engine/result.py:1353(all)
1 4.393 /usr/local/lib/python3.10/site-packages/sqlalchemy/orm/loading.py:1108(_populate_full)