You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@skywalking.apache.org by GitBox <gi...@apache.org> on 2021/06/02 07:19:13 UTC
[GitHub] [skywalking-banyandb] lujiajing1126 opened a new pull request #5: Feat: query module
lujiajing1126 opened a new pull request #5:
URL: https://github.com/apache/skywalking-banyandb/pull/5
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [skywalking-banyandb] lujiajing1126 commented on pull request #5: Feat: query module
Posted by GitBox <gi...@apache.org>.
lujiajing1126 commented on pull request #5:
URL: https://github.com/apache/skywalking-banyandb/pull/5#issuecomment-860367865
> From my perspective, the logical plan can't determine which indices should be used, which causes we can't optimize the logical plan before transferring it to physical plans. The reason is we don't support the composited index. A field doesn't exist in more than one index rule, which causes the logical plan doesn't have to select a better rule in a collection. In another word, field criteria separate from each other. I didn't find any paths to do optimization in current step.
So as I understood, in our scenario, the indexed to be used is determinant which does not need further optimization, at least for now, right?
A DAG is hard to be optimized. If we need, we might be better to have a hierarchical structure as a logical plann.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [skywalking-banyandb] hanahmily commented on pull request #5: Feat: query module
Posted by GitBox <gi...@apache.org>.
hanahmily commented on pull request #5:
URL: https://github.com/apache/skywalking-banyandb/pull/5#issuecomment-861113325
> So I suppose, in our context, we can generate/choose an already optimized "logical" plan according to the criteria instead of optimizing an existing set of logical plans like what a general databse does.
got your point. banyandb will implement rule-based and cost-based optimization. The first is the "logical" plan as you mentioned, and the latter is the physical one. Based on that, if the "DAG" path is too rigid to adapt to cost-based optimization, we might choose another solution for the architecture of the execution plan.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [skywalking-banyandb] lujiajing1126 commented on pull request #5: Feat: query module
Posted by GitBox <gi...@apache.org>.
lujiajing1126 commented on pull request #5:
URL: https://github.com/apache/skywalking-banyandb/pull/5#issuecomment-862230292
> > So I suppose, in our context, we can generate/choose an already optimized "logical" plan according to the criteria instead of optimizing an existing set of logical plans like what a general databse does.
>
> got your point. banyandb will implement rule-based and cost-based optimization. The first is the "logical" plan as you mentioned, and the latter is the physical one. Based on that, if the "DAG" path is too rigid to adapt to cost-based optimization, we might choose another solution for the architecture of the execution plan.
Yes. After some investigation, I found tree-structured logical plan may be more suitable for our cases,
- use rule-based optimization for logical plan
- generate multiple physical plans and choose the best one based on cost-based optimizer
while DAG is still feasible for a physical plan. I will continue working on this PR.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [skywalking-banyandb] hanahmily commented on pull request #5: Feat: query module
Posted by GitBox <gi...@apache.org>.
hanahmily commented on pull request #5:
URL: https://github.com/apache/skywalking-banyandb/pull/5#issuecomment-860355132
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [skywalking-banyandb] lujiajing1126 commented on pull request #5: Feat: query module
Posted by GitBox <gi...@apache.org>.
lujiajing1126 commented on pull request #5:
URL: https://github.com/apache/skywalking-banyandb/pull/5#issuecomment-860476382
> > the indexed to be used is determinant which does not need further optimization
>
> No. Once composite indices are introduced, we should choose which index or indices should be used, and ignore some particular index.
I see.
> > A DAG is hard to be optimized.
>
> Isn't the DAG composited by request/query? The DAGs should be varied depending on the criteria.
No. I mean as long as a DAG is generated, it is hard to optimize it since we can only know its parents and children during the walk.
So I suppose, in our context, we can generate/choose an already optimized "logical" plan according to the criteria instead of optimizing an existing set of logical plans like what a general databse does.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [skywalking-banyandb] lujiajing1126 closed pull request #5: Feat: query module
Posted by GitBox <gi...@apache.org>.
lujiajing1126 closed pull request #5:
URL: https://github.com/apache/skywalking-banyandb/pull/5
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@skywalking.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [skywalking-banyandb] hanahmily edited a comment on pull request #5: Feat: query module
Posted by GitBox <gi...@apache.org>.
hanahmily edited a comment on pull request #5:
URL: https://github.com/apache/skywalking-banyandb/pull/5#issuecomment-860381458
> the indexed to be used is determinant which does not need further optimization
No. Once composite indices are introduced, we should choose which index or indices should be used, and ignore some particular index.
> A DAG is hard to be optimized.
Isn't the DAG composited by request/query? The DAGs should be varied depending on the criteria.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [skywalking-banyandb] lujiajing1126 edited a comment on pull request #5: Feat: query module
Posted by GitBox <gi...@apache.org>.
lujiajing1126 edited a comment on pull request #5:
URL: https://github.com/apache/skywalking-banyandb/pull/5#issuecomment-860476382
> > the indexed to be used is determinant which does not need further optimization
>
> No. Once composite indices are introduced, we should choose which index or indices should be used, and ignore some particular index.
I see.
> > A DAG is hard to be optimized.
>
> Isn't the DAG composited by request/query? The DAGs should be varied depending on the criteria.
No. I mean as long as a DAG is generated, it is hard to optimize it since we can only know its parents and children during the graph walk.
So I suppose, in our context, we can generate/choose an already optimized "logical" plan according to the criteria instead of optimizing an existing set of logical plans like what a general databse does.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org