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

Allow more function nesting in InfluxQL #7438

Closed
Tomcat-Engineering opened this issue Oct 10, 2016 · 3 comments
Closed

Allow more function nesting in InfluxQL #7438

Tomcat-Engineering opened this issue Oct 10, 2016 · 3 comments

Comments

@Tomcat-Engineering
Copy link
Contributor

Feature Request

Proposal: Allow most functions in InfluxQL to be nested. Simplify and document the rules about which combinations are valid.

Current behavior: Not many functions allow nesting, so for example this query is forbidden even though it might be useful:

SELECT last(elapsed(value)) FROM ...

It is also not clear from the documentation (or the code!) which combinations are allowed. For example, you are allowed to do this:

SELECT derivative(mean(Alloc)) FROM runtime WHERE time > now() - 1d GROUP BY time(1h)

but not this:

SELECT max(mean(Alloc)) FROM runtime WHERE time > now() - 1d GROUP BY time(1h)

I wrote a new function but found it difficult to integrate with the query language because the nesting rules for each function seem to be individually hand-crafted - there was no way to say "this is another aggregator, just apply the normal aggregator rules and let people use it wherever an aggregator is valid".

Desired behavior: You can nest any functions as deeply as you like, subject to a few rules based on the function categories.

The function categories are already defined in the documentation but are not used much in the code. They already effectively determine the behaviour in many situations (particularly group-by queries), although these rules are not currently explicit in either the code or the documentation.

Use case: There are many cases where nesting functions is useful. Many of the proposed future functions are "single-point operators" like sqrt or sin and users will definitely expect to be allowed to nest these.

Specifying function composition rules in terms of categories rather than on a per-function basis will be a lot more scalable as more functions are added, and will make the behaviour easier to document.

@jsternberg
Copy link
Contributor

I think this is likely going to be implemented by subqueries. I think we have an issue for that open somewhere, but I'll have to find it. For math functions (which we have none at the moment, but we do plan to add those at some point) like pow() and sqrt, those will be nestable and they will get treated the same as if they were normal variable references whenever we get around to that. I should make an issue to discuss the implementation of that.

@jsternberg
Copy link
Contributor

Related to #4619.

@jsternberg
Copy link
Contributor

This can be done with subqueries.

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

No branches or pull requests

3 participants