Design approach for summarization prescriptions #473
MikeSpreitzer
started this conversation in
Ideas
Replies: 2 comments 3 replies
-
I assume you have checked for any intersection between CEL and SQL already? In other words, an opensource project that maps these to each other? |
Beta Was this translation helpful? Give feedback.
2 replies
-
Andrea Greggo asked - "What is the performance profile/efficiency of CEL?" |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I made a summarization proposal last year, you can see it in https://docs.google.com/document/d/1yY-XgOtCnOPKpVdxdPVhH5ixRN6IWQQe0s3lip1ID0Y/edit (accessible to members of the
kubestellar-dev
Google group). I am considering updating that for contribution here. I have a few high-level choices to make.The main thrust of the revision is to align more closely with aggregation in SQL. Following is the draft I have so far.
The AggregatorTypes that apply to numbers would involve recognizing the extracted JSON as numbers.
One question is whether to continue with the simple JSON extraction oriented approach above, or switch to CEL.
If we stick with the simpler approach shown above then it translates very directly to SQL, which may turn out to be a practical value. We may want to actually do that, at some point in the future. However, the direct translation only applies when all the Expressions are of the Path type; the Switch type ones are more iffy. I am not sure about translating them.
One reason for the inclusion of the switch type Expressions is to make it simple to request histograms. Perhaps instead we should add histogram as an AggregatorType?
CEL is more expensive to evaluate. But allows type-checking, at least for down-synced objects. But translating to SQL is more of an issue.
Beta Was this translation helpful? Give feedback.
All reactions