And before you demonize Calcite, Ted, let’s make it clear that we don’t know whether Calcite is to blame here. I actually doubt that it is, because AFAIK Kylin does not use Calcite for cuboid selection.
Sarnath’s original remark was > if SQL parsing is CPU intensive, it should not really take 100ms > unless some IO is being performed. SQL parsing absolutely should not take 100ms. It’s sometimes justified for the whole query preparation process to take 100ms — if that’s what it takes to find a “smart” way to answer the query, and the query would take a long time to answer otherwise. But if there’s a performance problem in the query preparation process, let’s log a performance bug, and identify where the time is being spent. Julian > On Nov 16, 2015, at 9:19 AM, Ted Dunning <[email protected]> wrote: > > On Tue, Nov 17, 2015 at 2:08 AM, Sarnath <[email protected]> wrote: > >> Thank you Ted, Luke. I think GLB problem hits when you have not built the >> cuboid that matches the exact group by statement in the query. That's when >> one needs to think how to satisfy the query. >> > > Yes. Exactly correct. > > But you still pay for carrying the optimizer around because it has a design > that costs a bit to get started.
