-
Notifications
You must be signed in to change notification settings - Fork 64
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
Add logical planer and select caching #79
Changes from all commits
a5bfdfa
043ac60
89b6a22
596ab0e
03538e8
dc26786
0711911
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,28 @@ | ||
// Copyright (c) The Thanos Community Authors. | ||
// Licensed under the Apache License 2.0. | ||
|
||
package logicalplan | ||
|
||
import ( | ||
"fmt" | ||
|
||
"github.com/prometheus/prometheus/model/labels" | ||
"github.com/prometheus/prometheus/promql/parser" | ||
) | ||
|
||
type FilteredSelector struct { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. So this seems to change PromQL spec and adds a new There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That's true, we are adding a new AST node type, similar to how StepInvariant was added upstream: https://github.com/prometheus/prometheus/blob/96d5a32659f0e3928c10a771e50123fead9828bd/promql/parser/ast.go#L178-L183 However, this is not changing the actual spec of PromQL. It only changes the parsed AST. In the best case scenario we would have our own structs copied from the AST and work with them. I thought that might be an overkill for now so I decided to start with something simpler. If something like this was added to upsteram PromQL, I would expect some tests to fail somewhere :) I am not sure if there is a better way to prevent such incompatibilities, and I don't also see how exactly they would manifest. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ack! I see! This makes sense, thanks! There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, we have to extend AST if we want to reuse it and avoid transforming types too many times. |
||
*parser.VectorSelector | ||
Filters []*labels.Matcher | ||
} | ||
|
||
func (f FilteredSelector) String() string { | ||
return fmt.Sprintf("filter(%s, %s)", f.Filters, f.VectorSelector.String()) | ||
} | ||
|
||
func (f FilteredSelector) Pretty(level int) string { return f.String() } | ||
|
||
func (f FilteredSelector) PositionRange() parser.PositionRange { return parser.PositionRange{} } | ||
|
||
func (f FilteredSelector) Type() parser.ValueType { return parser.ValueTypeVector } | ||
|
||
func (f FilteredSelector) PromQLExpr() {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My worry is that this has to be extended to have different optimization modes, possible with https://yourbasic.org/golang/bitmask-flag-set-clear/
I guess we can break compatibility still and change it in future if needed.