[samhld]

(Solution architect at InfluxData here) Out of curiosity...what was the need for this DELETE? Deleting (not dropping) being somewhat of a "second class citizen" was a design choice to make room for more pressing time series needs. In my experience, `DELETE`ing is rarely necessary.

[silvester23]

We work a lot with forecast data and sometimes mistakes happen and a forecast gets written to the wrong time series or for the wrong period. In these cases we do not want to drop the complete time series but only delete the erroneous parts.

While it is indeed a rare occurence, it is also very slow.

[majkinetor]

I often use metrics for giving reports via Grafana. They are usually 99% correct which is good enough for many cases. The benefit of doing so is that you already need and have nice dashboard for devs to follow what is going on with the system real time, and its just grafana account distant from customer. So we do this on several big gov systems. Sometimes customers complain that there is a slight difference between real state and what metrics show but its not a big deal and rarelly happens (when you have millions of things, is it really important to know 100% precise value in majority of contexts?)

Recently my colegue was testing some script and added some huge numbers on metric that is used for one of those reports. We had to delete those tests as customer complained that now his total invoice number jumped to trillions.

[sgt]

It was actually a bunch of data that was inserted coming from an IoT device that was invalid. So just deleting that time period and limiting to a tag would have been sufficient.