Thanks for your feedback, Ben. Where did you look in the documentation that you didn't see mention of retention policies in the query? We do discuss it a number of places but could always add more.
On Fri, Jul 15, 2016 at 3:04 PM, 'Ben Hastings' via InfluxDB < [email protected]> wrote: > I haven't tried backfilling yet, but I did come across something > unexpected. > > I am using my CQ to roll up timers into a timers_1m measurement. When I > execute SHOW MEASUREMENTS, I see timers_1m there. So, I try > > select * from timers_1m where time > now() - 5m > > and get "success" but nothing else. After digging around some more, I > tried changing my query to: > > select * from "minute_52w".timers_1m where time > now() - 5m (where > "minute_52w" is the retention policy) > > then I get all of the data! That is in every possible way not expected. > I was under the impression that retention policies were more transparent, > behind the scenes... a means of managing the amount of data stored in the > system, not a very front-and-center requirement for querying. I even tried > hitting it in chronograf and grafana (interestingly, grafana was able to > navigate and find the records once I added the RP, chronograf wasn't) > > This seems very not-intuitive for someone who comes to the data - either > the influx interface or chronograf - to explore or interact with the data. > If they did as I, and just did a SHOW MEASUREMENTS, it's not a logical next > step to try retention policies in order to find the data. > > I guess I added all of that to say, either the documentation needs fleshed > out tremendously, example queries need to be expanded, or rethinking how > queries on measurements with RP's involved is required. > > Aside from this, I'm really enjoying influxDB so far. Telegraf is great, > too.... chronograf needs some work, and I WANT to dig in with kapacitor, > just haven't had the opportunity yet. > > All the Best, > Ben > > > > On Friday, July 15, 2016 at 4:52:13 PM UTC-4, Sean Beckett wrote: >> >> I properly should have said there's no way to schedule a backfill query. >> CQs and bqckfill queries both involve INTO clauses. >> >> The CQ should be logging when it runs. Do you see log entries for it? Are >> CQs enabled in the config file? Can you include the output from SHOW >> CONTINUOUS QUERIES? >> >> On Fri, Jul 15, 2016 at 8:01 AM, <[email protected]> wrote: >> >>> I'm having a similar challenge with a CQ created according to the >>> documentation. The DB shows the CQ exists, and if I execute a backfill >>> query as given in the documentation, data is populated, but there is >>> nothing automatically being added to the DB. >>> >>> The specific question I have is that documents show the "INTO" being >>> necessary if one wants to write to a specific retention policy. That seems >>> to contradict the "no way to schedule an INTO query" by Sean. >>> >>> Any help is appreciated. >>> >>> I'm working from the most recent documentation (matching the 1.0.0 beta2 >>> we're using for evaluating this stack) - >>> https://docs.influxdata.com/influxdb/v1.0/query_language/continuous_queries/ >>> >>> On Tuesday, May 24, 2016 at 11:43:50 AM UTC-4, Sean Beckett wrote: >>> > CQs only run against newly arrived data. INTO queries run against >>> arbitrary time ranges. There is no way to schedule an INTO query. >>> > >>> > >>> > Use INTO queries to backfill your previous data. Use CQs to downsample >>> newly arriving data. >>> > >>> > >>> > CQs do not respect any WHERE time clause. use GROUP BY time(1d) to >>> have the CQ run daily. See the docs for more: >>> https://docs.influxdata.com/influxdb/v0.13/query_language/continuous_queries/ >>> > >>> > >>> >>> Sean Beckett >> Director of Support and Professional Services >> InfluxDB >> > -- > Remember to include the InfluxDB version number with all issue reports > --- > You received this message because you are subscribed to the Google Groups > "InfluxDB" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/influxdb. > To view this discussion on the web visit > https://groups.google.com/d/msgid/influxdb/25bf6d02-3302-4d24-8ace-c8a01e4ffdbc%40googlegroups.com > <https://groups.google.com/d/msgid/influxdb/25bf6d02-3302-4d24-8ace-c8a01e4ffdbc%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- Sean Beckett Director of Support and Professional Services InfluxDB -- Remember to include the InfluxDB version number with all issue reports --- You received this message because you are subscribed to the Google Groups "InfluxDB" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/influxdb. To view this discussion on the web visit https://groups.google.com/d/msgid/influxdb/CALGqCvM5zX7Ns-2sQh%2BM5LvfuuMeOoyY_jthx%2BVWPOfFc%3D-h6Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
