Yes, before proposing pagination for these endpoints I spent some time profiling the current queries generated by the simple tenant usage endpoints, and can confirm that they were significantly improved since this bug was initially reported.
That said, 1 tenant with 20,000+ instances is still going to be problematic without paging of some kind unless the server_usages details (via detailed=1) are removed from the API response and the aggregation is moved to the SQL (with a GROUP BY tenant_id clause).
As of stable/newton, the query generated looks like this (note: I replaced the individual fields with stars for brevity):
SELECT instances.*, instance_extra.*
FROM instances
LEFT OUTER JOIN instance_extra ON instance_extra.instance_uuid = instances.uuid
WHERE (instances.terminated_at IS NULL OR instances.terminated_at > '2016-09-28 21:02:51') AND instances.launched_at < '2016-09-28 21:02:51';
Yes, before proposing pagination for these endpoints I spent some time profiling the current queries generated by the simple tenant usage endpoints, and can confirm that they were significantly improved since this bug was initially reported.
That said, 1 tenant with 20,000+ instances is still going to be problematic without paging of some kind unless the server_usages details (via detailed=1) are removed from the API response and the aggregation is moved to the SQL (with a GROUP BY tenant_id clause).
As of stable/newton, the query generated looks like this (note: I replaced the individual fields with stars for brevity):
SELECT instances.*, instance_extra.* extra.instance_ uuid = instances.uuid terminated_ at IS NULL OR instances. terminated_ at > '2016-09-28 21:02:51') AND instances. launched_ at < '2016-09-28 21:02:51';
FROM instances
LEFT OUTER JOIN instance_extra ON instance_
WHERE (instances.