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

fill(none) does not apply to count() #5042

Closed
hoomanv opened this issue Dec 8, 2015 · 12 comments · Fixed by #5076
Closed

fill(none) does not apply to count() #5042

hoomanv opened this issue Dec 8, 2015 · 12 comments · Fixed by #5076
Assignees
Milestone

Comments

@hoomanv
Copy link

hoomanv commented Dec 8, 2015

I have this query

select count(value) from event where time > now() - 1d and time < now() group by time(1m) fill(none)

And the result has 1440 records even for those empty intervals
If I change the query to

select count(value),max(value) from event where time > now() - 1d and time < now() group by time(1m) fill(none)

It will leave empty intervals out

So basically count() alone is not taken into account by fill(none).
But I believe it should have.

@corylanou
Copy link
Contributor

Are you on nightly? This got pushed to master yesterday and might fix that issue: #5000

@hoomanv
Copy link
Author

hoomanv commented Dec 8, 2015

No I'm not. I will see if I can install the rpm and test it

@hoomanv
Copy link
Author

hoomanv commented Dec 8, 2015

I just tested it against 0.9.7_nightly_9c65e17-1 and still seems broken

@corylanou
Copy link
Contributor

Ok. Thanks. @nathanielc is this something you want to look at since you were just in there? Adding a test should be easy enough based on the info above I think.

@otoolep
Copy link
Contributor

otoolep commented Dec 8, 2015

Count should always returns 0 for intervals without points. That is the
definition of count, and therefore doesn't return an empty interval. The
interval will have a value zero.

Fill does not apply to count.

On Tuesday, December 8, 2015, Cory LaNou notifications@github.com wrote:

Ok. Thanks. @nathanielc https://github.com/nathanielc is this something
you want to look at since you were just in there? Adding a test should be
easy enough based on the info above I think.


Reply to this email directly or view it on GitHub
#5042 (comment).

@corylanou
Copy link
Contributor

@otoolep I think he is saying he isn't getting intervals, and he should because count should always be zero. I agree that fill(none) shouldn't have an affect, but still feels like a bug in here.

@hoomanv can you show us some sample outputs in a gist for each query so we can understand this better?

@hoomanv
Copy link
Author

hoomanv commented Dec 9, 2015

May be I wasn't clear enough. I am getting 0 counts for intervals without points. But I expected that fill(none) would eliminate 0 counts. This can be more illustrative with an example:

We write a point to the QueueEvent measurement every time a token arrives or leaves a queue.
Line protocol looks something like this: QueueEvent,queue=1 token="abc",length=8i
There is a CQ that rolls up the number of QueueEvents that occurred by 1 minute intervals.
That is generating a lot of zeros which are useless and just waste storage.

If count() is not meant for this, then we need another count function that excludes zeros if fill(none)

@otoolep
Copy link
Contributor

otoolep commented Dec 9, 2015

You make a good point.

@pauldix -- after we changed count to always return 0, it is now not possible to suppress zero values in the output.

@nathanielc
Copy link
Contributor

I agree fill none should suppress counts of zero. This should be similar to
my previous change.
On Dec 9, 2015 11:56 AM, "otoolep" notifications@github.com wrote:

You make a good point.

@pauldix https://github.com/pauldix -- after we changed count to always
return 0, it is now not possible to suppress zero values in the output.


Reply to this email directly or view it on GitHub
#5042 (comment).

@pauldix
Copy link
Member

pauldix commented Dec 9, 2015

agree

@otoolep
Copy link
Contributor

otoolep commented Dec 9, 2015

OK, sending your way @nathanielc - sound good?

@hoomanv
Copy link
Author

hoomanv commented Dec 10, 2015

Thank you for your great support.

@jwilder jwilder added this to the 0.10.0 milestone Feb 1, 2016
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

Successfully merging a pull request may close this issue.

6 participants