8000 [feature]: support comparison binary operations · Issue #912 · lindb/lindb · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

[feature]: support comparison binary operations #912

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.

Sign up for GitHub

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

Jump to bottom
Closed
stone1100 opened this issue Feb 19, 2023 · 6 comments
Closed

[feature]: support comparison binary operations #912

stone1100 opened this issue Feb 19, 2023 · 6 comments
Labels
feature New feature

Comments

@stone1100
Copy link
Member

Is your feature request related to a problem? Please describe.

  • field support comparison binary operations

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.
@stone1100 stone1100 added the feature New feature label Feb 19, 2023
@joyant
Copy link
Contributor
joyant commented Nov 17, 2023

Hi there!

I'd like to work on this issue. 🚀Let's make this happen! 💪

Please forgive me for not fully understanding the meaning of this issue. What I can think of is that you hope that lindb can support the following SQL statement query:

select x, y, z from a where x > 10.1 and y < 5.2; // x, y and z are all fields

Can you tell me whether my understanding is correct? If not, please describe this issue in more detail. Thank you.

@stone1100
Copy link
8000
Member Author

✌️ , Welcome to contribute LinDB together.

Yes, you are right.

Some cases like this:

select x, y, z from a>10.1; // fields

select x+y as a, 2*z, z from a>10 and 2*z>10; // expr

select sum(x) as a from a>10; // function

@joyant
Copy link
Contributor
joyant commented Dec 1, 2023

✌️ , Welcome to contribute LinDB together.

Yes, you are right.

Some cases like this:

select x, y, z from a>10.1; // fields

select x+y as a, 2*z, z from a>10 and 2*z>10; // expr

select sum(x) as a from a>10; // function

  1. In your example, there is no specification of the metric, and there is no 'WHERE' keyword. Is this just a shorthand form, or is it a formal syntax?

  2. When you need to simultaneously filter based on both tags and fields, what should the SQL statement look like?

  3. In this example, would it be better to use the HAVING clause?

select sum(x) as a from a>10; // function
=>
select sum(x) as a from metric_x having a > 10;

@joyant
Copy link
Contributor
joyant commented Dec 1, 2023

If I make any mistakes, please feel free to interrupt me.

Filtering for fields can only be done at the root node of the broker because it requires aggregating results from all intermediate nodes or storage nodes in the broker. Only when all families from all shards are aggregated by interval can the data that doesn't meet the WHERE conditions be filtered out. Implementing this feature in root_metric_context.go might be the most suitable approach.

For queries involving GROUP BY time in standard SQL, field filtering should occur before grouping. In other words, fields that do not meet the conditions should not be included in the group calculation. However, for Lindb, filtering of fields should occur after grouping. In this case, filtering fields behaves similarly to the HAVING clause. Therefore, if Lindb supports HAVING queries, the following two SQL statements would be equivalent.

select * from a where field_a = 1 group by time(1m); // Assuming this is valid.
select * from a group by time(1m) having field_a = 1;

The field condition may not necessarily appear in the selectExpr, which also determines some modifications in certain operators.

@stone1100
Copy link
Member Author

I made a mistake.
There are 2 scenarios here.

  1. Before grouping aggregate, filtering raw value of field.
    select * from a where field_a =1
  2. After grouping aggregate, filtering the result of grouping. Like you said group by having statement is better.
    select * from a group by time(1m) having field_a = 1; // using default aggregate function

Let's implement scenario 2 first, and at the same time, like standard SQL, the field condition must appera in the selectExpr?

@stone1100
Copy link
Member Author

If I make any mistakes, please feel free to interrupt me.

Filtering for fields can only be done at the root node of the broker because it requires aggregating results from all intermediate nodes or storage nodes in the broker. Only when all families from all shards are aggregated by interval can the data that doesn't meet the WHERE conditions be filtered out. Implementing this feature in root_metric_context.go might be the most suitable approach.

For queries involving GROUP BY time in standard SQL, field filtering should occur before grouping. In other words, fields that do not meet the conditions should not be included in the group calculation. However, for Lindb, filtering of fields should occur after grouping. In this case, filtering fields behaves similarly to the HAVING clause. Therefore, if Lindb supports HAVING queries, the following two SQL statements would be equivalent.

select * from a where field_a = 1 group by time(1m); // Assuming this is valid.
select * from a group by time(1m) having field_a = 1;

The field condition may not necessarily appear in the selectExpr, which also determines some modifications in certain operators.

Yes, grouping field filtering only be done in the root node before building result set.

joyant added a commit to joyant/lindb that referenced this issue Dec 10, 2023
@joyant
[feat:lindb#912]: support comparison binary operations
0fec149
joyant added a commit to joyant/lindb that referenced this issue Dec 10, 2023
@joyant
[feat:lindb#912]: support comparison binary operations
017d061
@joyant joyant mentioned this issue Dec 10, 2023
Merged
3 tasks
stone1100 pushed a commit that referenced this issue Dec 14, 2023
@joyant
[feat:#912]: support comparison binary operations (#1000)
a852fe5
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
feature New feature
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@stone1100 @joyant
0