You're correct that it's not a single value. That said, in practice, not much is actually done with. CPU or I/O cost. You'll see in TableScan that computeSelfCost returns a cost which really only makes use of the number of rows in the table. Individual adapters may override this, but few do. -- Michael Mior [email protected]
Le mer. 6 févr. 2019 à 05:22, Lekshmi <[email protected]> a écrit : > > Hi, > In [0], they suggest, "the optimizer implementer can choose the cost to be > a number or record". Which does one Apache Calcite use? I found, it as a > record, when I run queries in debug mode. Is that correct? Then can you > please define (rows, CPU, I/O) in Calcite? Also, when, we are connecting > calcite across multiple systems, then 'i/o' should be greater than '0.0', > right? Because it needs to read the results from the push-down operations? > Can you please explain these in a bit more detail? I appreciate your > support and suggestions. > > > Thanks and Regards > > Lekshmi B.G > Email: [email protected] > > > > > On Tue, Feb 5, 2019 at 11:30 PM Michael Mior <[email protected]> wrote: > > > Calcite's optimizer is based off the Volcano optimizer[0]. In that > > paper you'll find an outline of the algorithm which is basically > > equivalent to what Calcite uses. Adding multiple systems doesn't > > complicate things very much. The main addition used by Calcite is what > > we call a "convention" trait that allows the optimizer to deal with > > expressions across multiple systems. More details are available in a > > recently published paper on Calcite [1]. > > > > One important caveat to note is that the cost model used is not likely > > to reflect the actual cost of query execution in many cases. It's > > generally "good enough" in that the ordering of plans by cost will be > > approximately correct. So although the optimal plan will be selected > > according to the cost model, the plan which is actually the best in > > practice may not be selected. That said, I would expect Calcite will > > pick a plan which is generally quite close to the optimal, but we > > have no guarantee of this. > > > > [0] > > https://pdfs.semanticscholar.org/a817/a3e74d1663d9eb35b4baf3161ab16f57df85.pdf > > [1] https://arxiv.org/pdf/1802.10233.pdf > > > > -- > > Michael Mior > > [email protected] > > > > Le mar. 5 févr. 2019 à 15:52, Lekshmi <[email protected]> a écrit : > > > > > > Hi, > > > I would like to know about the Calcite CBO in detail, including how it > > > deals with global optimization when multiple processing systems are > > > associated with it. Any documentation, pointers are much appreciated. > > > > > > > > > Thanks and Regards > > > > > > Lekshmi B.G > > > Email: [email protected] > >
