Hi Stamatis, Thanks a lot for your reply. Yes, it seems the traits currently in Calcite are used by the optimizer. I wonder whether we can extend it for other use-cases. For example, I want to provide a way to the users that they can set memory or cpu settings for an aggregate node from the user api. These settings will only be used after optimization.
I haven't found other ways to achieve this, so maybe using trait is a neat way? Best, Hequn On Fri, Jan 18, 2019 at 12:00 AM Stamatis Zampetakis <[email protected]> wrote: > Hi Hequn, > > I would describe traits as properties associated with RelNodes that provide > useful information to the optimizer (rules etc.) in order to generate a > plan. > > If the configuration you are referring to is meant to guide the optimizer > in generating a plan then it seems ok to use traits. If not then probably > you need something different. > > Can you elaborate a bit more on your usecase? > > Best, > Stamatis > > > On Tue, Jan 15, 2019, 10:57 AM Hequn Cheng <[email protected] wrote: > > > Hi Julian, > > > > Thanks a lot for your reply and the detailed explanation. It solves my > > doubts well. > > My custom trait only contains one value, so I think that there will not > be > > a problem. > > > > May I further the email with another question: > > Is it ok or right to use a trait to pass configurations through RelNodes? > > For example, a configuration set from api for the aggregate and used > after > > the optimization. > > If not, are there any standard ways to achieve this? > > > > I haven't found any clear definition about trait. Only find comments in > > code: *RelTrait represents the manifestation of a relational expression > > trait within a trait definition.* > > > > Thank you! > > > > On Tue, Jan 15, 2019 at 3:12 AM Julian Hyde <[email protected]> wrote: > > > > > In most cases increasing the number of traits from one to two will > > > increase the planning time by a negligible amount. > > > > > > But it can increase the size of the search space. Suppose a particular > > > relational expression has 5 possible sort orders (order by x, order by > x, > > > y, order by (), order by z, order by x, z), and initially you have only > > the > > > collation trait enabled. A particular equivalence set might have 5 > > subsets, > > > one for each sort order. Now let’s suppose you add the distribution > trait > > > to the mix, and there are 3 distributions (partition by (), partition > by > > x, > > > partition by z). Now that subset will have 15 subsets, for the > cartesian > > > product of the traits. > > > > > > A larger search space could increase the planning time (and memory > usage) > > > significantly. > > > > > > But if each trait has only one or two values I doubt that there will > be a > > > problem. > > > > > > Julian > > > > > > > > > > On Jan 14, 2019, at 1:38 AM, Hequn Cheng <[email protected]> > wrote: > > > > > > > > Hi everyone, > > > > > > > > I want to pass properties through RelNodes via trait and I wonder if > > the > > > > number of traits in traitSet will affect the time of Volcano > > > optimization. > > > > For example, increasing one traitDef to two in VolcanoPlanner. > > > > > > > > I guess the answer is No. Is it correct? > > > > As long as the search space is not increased, the Volcano > optimization > > > time > > > > will not increase. And simply increasing the number of traits alone > > does > > > > not add complexity. > > > > > > > > Furthermore, besides time, are there any other side effects if I > > increase > > > > the number of traits? > > > > > > > > Thank you very much! > > > > > > > > Best, > > > > Hequn > > > > > > > > >
