You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Other adapters such as juttle-elastic-adapter support -optimize false in the read to send the execution down unoptimized path. This has been useful in debugging, let's support it for opentsdb as well.
Now, opentsdb currently doesn't optimize anything besides the read filters, but even for those it can be useful to have a completely unoptimized read (ie: read everything for the given metric name) where filtering happens in juttle runtime. And definitely needed once optimizations for reduce/etc are added.
The text was updated successfully, but these errors were encountered:
If the point of this option is to help internal development / debugging then I question whether it's really useful to propagate this more widely to other adapters. I certainly would be wary of making it part of the adapter template.
Thinking more about it, I don't really see why we need this at all... in order to test filters in the read vs filters after the fact, we can change read adapter <filter> to read adapter | filter <filter>. To test optimized vs non-optimized reduce, one can change read adapter | reduce to read adapter | pass | reduce.
We have used this in debugging with end user; it was easier to advise adding -optimize false than restructuring their program in multiple ways, so I came away thinking its a handy tool to support in adapters generally. It also serves as an easy documented workaround in case of hitting optimization bugs.
If you don't think it's useful in principle let's discuss on juttle/juttle#84 which is the cross-adapter unification task.
Other adapters such as juttle-elastic-adapter support -optimize false in the read to send the execution down unoptimized path. This has been useful in debugging, let's support it for opentsdb as well.
Now, opentsdb currently doesn't optimize anything besides the read filters, but even for those it can be useful to have a completely unoptimized read (ie: read everything for the given metric name) where filtering happens in juttle runtime. And definitely needed once optimizations for reduce/etc are added.
The text was updated successfully, but these errors were encountered: