<div dir="ltr"><div>Hello Thomas,</div><div><br></div><div>Storing data frames in SQL is only supported by the v1 storage interface: <a href="https://docs.openstack.org/cloudkitty/latest/admin/configuration/storage.html">https://docs.openstack.org/cloudkitty/latest/admin/configuration/storage.html</a></div><div>The v2 storage interface introduced InfluxDB and Elasticsearch as replacement.</div><div><br></div><div>I believe the plans of the previous core team was to deprecate v1 storage [1], so I am not sure we'll want to put lots of effort in supporting it.</div><div>However feel free to propose a patch, if it's trivial enough I don't see why we wouldn't merge it.</div><div><br></div><div>[1] <a href="https://docs.openstack.org/releasenotes/cloudkitty/stein.html#new-features">https://docs.openstack.org/releasenotes/cloudkitty/stein.html#new-features</a></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 23 Jul 2021 at 16:25, Thomas Goirand <<a href="mailto:zigo@debian.org">zigo@debian.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
Very fast, with only a few resources, the rated_data_frames tables<br>
becomes huge.<br>
<br>
I was very surprised to see there's absolutely zero index in this table.<br>
Isn't a "openstack rating dataframes get" querying this table, with<br>
tenant_id and begin / end as filters? Wouldn't the API calls be a lot<br>
more efficient with such indexes?<br>
<br>
Cheers,<br>
<br>
Thomas Goirand (zigo)<br>
<br>
</blockquote></div></div>