As Yingyi pointed out we don't reorder joins because the framework for stats and cardinalities is not there yet. However what we can do in an meantime is to provide an interface for the statistical information, needed for join reordering, independent of the way the stats were collected (either sampling-based or LSM-based) and work out details of the cost model.
2016-10-31 11:30 GMT-07:00 mingda li <[email protected]>: > Hi Yingyi, > > I see. Thanks for your reply:-) > > Bests, > Mingda > > > On Mon, Oct 31, 2016 at 11:23 AM, Yingyi Bu <[email protected]> wrote: > > > Mingda, > > > > I'm not sure how much re-ordering can be done at the Hyracks level, > > i.e., the runtime level. > > In the optimizer (the asterixdb/algebricks level), we don't have > > re-ordering for joins, because: > > --- the cost model has not been added yet. I'm not sure about the > > timeline for this. @Ildar? > > --- respecting user-specified join orders is important for certain > > cases, for example, to get stable/predictable performance (zero surprise) > > for applications. > > > > In the runtime, we have a role-reversal optimization in hybrid hash > > join, which is a safe optimization that is not based on estimations. You > > can look at OptimizedHybridHashJoin. > > > > Best, > > Yingyi > > > > > > On Mon, Oct 31, 2016 at 11:16 AM, mingda li <[email protected]> > > wrote: > > > > > Dear all, > > > > > > Hi, I am working on multiple join on Hyracks level. I am not sure if I > do > > > the multiple join on AsterixDB, whether it will optimize the query by > > > changing the join order or just execute according to how we write the > > > query. I think this may not be done in Algebricks level based on rule > but > > > not sure. > > > > > > Bests, > > > Mingda > > > > > > -- Best regards, Ildar
