Hi Vladmir, Thanks for your feedback.
IMO, Root[$0] should depend on t.a and t.b, because the value of t.b decides if some value could be included in Root[$0]. However, after investigating the code, I find you are right! The current implementation of RelMdColumnOrigins#getColumnOrigins(Filter, RelMetadataQuery, int) does not incorporate columns referenced in the condition. I am wondering if this is by design? Do we need another metadata query to evaluate the relation between input and output columns? Best, Liya Fan On Tue, Dec 22, 2020 at 3:50 PM Vladimir Ozerov <ppoze...@gmail.com> wrote: > Hi Liya, > > This will not work AFAIK. Consider the query "SELECT a FROM t WHERE b>1". > The top-level operator has only one column: > > Root[$0] > Project[$0] > Filter[$1>1] > Scan[$0=a, $1=b] > > If you invoke RelMdColumnOrigins on Root[$0], you will get [t.a], but miss > [t.b]. > To my knowledge, rules are the only way to reliably. constrain columns > returned from the scan. > > Regards, > Vladimir. > > вт, 22 дек. 2020 г. в 05:14, Fan Liya <liya.fa...@gmail.com>: > > > Hi Bhavya, > > > > Sorry I am not sure if I fully understand your question. > > > > Let me try to answer it according to my understanding: > > > > 1. Through RelColumnMDOrigins, we can get the RelColumnOrigin object, > which > > includes a RelOptTable object. > > 2. The table scan also has a RelOptTable object, and all table scans of > the > > plan can be found (e.g. through a visitor) > > 3. With the information of 1 and 2, given any output column, we can get > to > > know it is derived from which columns from which table scans. > > 4. With the information of 3, given a table scan, we can get to know > which > > column is never used in any output columns, and such columns can be > pruned. > > > > Best, > > Liya Fan > > > > > > On Mon, Dec 21, 2020 at 11:31 PM Bhavya Aggarwal <bha...@knoldus.com> > > wrote: > > > > > Hi Liya, > > > > > > I had a look at the RelColumnMDOrigins and it is useful in determining > > > which columns are from which table but still I am not sure how can I > get > > > the column information for TableScan without the rules. If you have any > > > specific example where we have used this approach will be really > helpful > > to > > > me. > > > > > > Thanks and regards > > > Bhavya > > > > > > On Mon, Dec 21, 2020 at 5:53 PM Fan Liya <liya.fa...@gmail.com> wrote: > > > > > > > Hi Bhavya, > > > > > > > > IMO, to solve the problem from a global view, the following steps > needs > > > to > > > > be taken: > > > > > > > > 1. Generate a physical plan in the original way (without considering > > > column > > > > pruning in the table scan) > > > > 2. Modify all the table scans in the plan with the RelColumnMDOrigins > > > > utility (the details have been described above) > > > > 3. Post process the plan with one of the following ways: > > > > a) a plan visitor that adjusts other operators in the tree. > > > > b) a light-weight planner (Hep or Volcano with limited rule sets) > > > > > > > > Run the query with the finally generated plan. > > > > > > > > Best, > > > > Liya Fan > > > > > > > > > > > > On Mon, Dec 21, 2020 at 3:33 PM Bhavya Aggarwal <bha...@knoldus.com> > > > > wrote: > > > > > > > > > Hi Fan, > > > > > > > > > > I looked at the class RelColumnMDOrigins and it is giving me the > > origin > > > > of > > > > > the column, but even if I want to take it as a global decision I am > > not > > > > > sure how to proceed. Can you please elaborate on how to achieve > this > > ? > > > I > > > > am > > > > > literally stuck as I do not want to use so many rules as in any > case > > I > > > > have > > > > > to pass these to the TableScan, even if the user does a select * > from > > > > > table, I need to add all those columns to the table scan. > > > > > > > > > > Regards > > > > > Bhavya > > > > > > > > > > -- > > > > > Your feedback matters - At Knoldus we aim to be very professional > in > > > our > > > > > quality of work, commitment to results, and proactive > communication. > > If > > > > > you > > > > > feel otherwise please share your feedback > > > > > <https://forms.gle/Ax1Te1DDpirAQuQ8A> and we would work on it. > > > > > > > > > > > > > > > > > > -- > > > *Bhavya Aggarwal* > > > CTO & Partner > > > Knoldus Inc. <http://www.knoldus.com/> > > > +91-9910483067 > > > Canada - USA - India - Singapore > > > <https://in.linkedin.com/company/knoldus> < > https://twitter.com/Knolspeak > > > > > > <https://www.facebook.com/KnoldusSoftware/> <https://blog.knoldus.com/ > > > > > > > > -- > > > Your feedback matters - At Knoldus we aim to be very professional in > our > > > quality of work, commitment to results, and proactive communication. If > > > you > > > feel otherwise please share your feedback > > > <https://forms.gle/Ax1Te1DDpirAQuQ8A> and we would work on it. > > > > > >
