Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Queries with relative times seem to be off #2045

Closed
pauldix opened this issue Mar 21, 2015 · 4 comments
Closed

Queries with relative times seem to be off #2045

pauldix opened this issue Mar 21, 2015 · 4 comments
Milestone

Comments

@pauldix
Copy link
Member

pauldix commented Mar 21, 2015

From this thread: https://groups.google.com/forum/?#!msg/influxdb/WLPOANOb0B8/HWC239vQbJUJ

Looks like queries with WHERE time > now() - 1h or something like that are doing weird things. Maybe a timezone thing? Something else? Please to investigate.

@pauldix pauldix added this to the 0.9.0 milestone Mar 21, 2015
@jnutzmann
Copy link

My apologies, but it looks like this is a bug that was mistakenly introduced in PR #2016. That said, there were issues with how the time for these queries was computed before (and the bucket problem).

When I added the code to NextInterval in tx.go, I assumed that interval was only greater than zero if there was truly an interval (group by in use). This is not the case, as Execute in engine.go sets it to the span between min time and max time. Therefore, NextInterval incorrectly tries to normalize the start time to a natural boundary when it shouldn't.

I think the solution is getting rid of m.interval = m.TMax - m.TMin on line 97 of engine.go, adding a check for zero on line 132 like this:

if m.interval > 0 {
    startTimeBucket = m.TMin / m.interval * m.interval
} else {
    startTimeBucket = m.TMin
}

then, in tx.go we can add an else case in NextInterval like this:

if interval > 0 {
    // Make sure the bottom of the interval lands on a natural boundary.
    intervalBottom = intervalBottom / interval * interval
    l.tmax = intervalBottom + interval - 1
} else {
    l.tmax = l.job.TMax
}

I have a local version running now and am working on testing it.

@jnutzmann
Copy link

This solution causes some group by queries to fail when a minimum time is not specified. I am tied up in meetings for the next few hours, but can get back to it after that.

@pauldix
Copy link
Member Author

pauldix commented Mar 25, 2015

This is fixed in RC16.

@nemesifier
Copy link

tested! 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants