Hi Julian,
thank you very much for your insights.
Your analysis is very detailed and I agree with all your suggestions.
For myself I started to realize the "big" differences between Calcites Use Case
and the PLC4X Case.
I will definitely have a look into the book advised by you (I like
The first step is to realize that you are looking at an optimization problem.
Congratulations, you’ve done that.
The next step is to evaluate the possible optimization techniques. Volcano is
suitable in cases where there is dataflow - where the solution is a tree or
DAG. It doesn’t seem that
Hi,
a short update on this matter.
We had a meetup yesterday with the PLC4X community and I prepared a very first
"demo" implementation of the Optimizer / Framework.
I tried to organize it after the Calcite / Volcano approach.
We had several discussions and experimented a bit and some things
Hi Stamatis,
thanks for your response.
I think my brain just needs a bit more time to get really deep into those
advanced planning topics (its sometimes slow on adopting...).
But I will look through it.
We have a meetup this week and will discuss the matter and how to setup
everything to enable
Hi Julian F,
I admit that I didn't really get your example but talking about 'batch
request optimization'
and 'collapsing "overlapping" but not equal requests' I get the impression
that the problem
is optimizing sets of queries which may have common sub-expressions;
the problem is usually
Hi Julian,
thanks for the reply.
I have to think about that, I think.
But as I understand the Spool Operator this is to factor out multiple
calculations of the same issue.
In our Situation we aim more on collapsing "overlapping" but not equal requests.
Consider 8 bits which form physically a
One tricky aspect is to optimize a *batch* of requests.
The trick is to tie together the batch so that it is costed as one request. We
don’t have an operator specifically for that, but you could for instance use
UNION ALL. E.g. given Q1 and Q2, you could generate a plan for
select count(*)
Hi Danny,
thanks for the quick reply.
Cost calculation we can of course provide (but it could be a bit different as
we have not only CPU and Memory but also Network or something).
And also something like the RelNodes could be provided. In our case this would
be "Requests" which are at first
Cool idea ! Julian Feinauer ~
I think the volcano model can be used the base of the cost algorithm. As long
as you define all the metadata that you care about. Another thing is that you
should have a struct like RelNode and a method like #computeSelfCost.
Best,
Danny Chan
在 2019年8月19日 +0800
Hi folks,
I’m here again with another PLC4X related question (https://plc4x.apache.org).
As we have more and more usecases we encounter situations where we send LOTS of
replies to PLCs which one could sometimes optimize.
This has multiple reasons upstream (like multiple different Services
10 matches
Mail list logo
