Comment 4 for bug 1489548

I think Zane is right and we should deprecate max_resources_per_stack and move to a tenant limit. And we should consider db schema changes to make that calculation as efficient as possible.

Having said that, last round of optimisation for stack resource count was aimed at memory use only, and avoided schema changes to lower the backporting impact. Now we know it is causing different scaling issues we still have a window to optimise *with* schema changes before liberty, and chances are this would benefit a tenant resource count too.

Likely the above template is slow purely due to database round trips. For the current implementation these are for each resource creation:
1) a db select per parent stack to navigate to the root stack
2) a db select per stack to discover all stack ids in the tree
3) a db count query of all resources in the

If the resource table had a root_stack_id column, the above would be replaced with a single count query. And if the stack table had a root_stack_id column then populating each resource.root_stack_id would not require extra queries.