I just had a conversation with Steven. There is third choice: if a variable is used after SELECT operator (which will be transformed into an UNNESTMAP operator), then we need to retainInput as true. Otherwise, we can set it as false. However, currently, the IntroduceSelectAccessMethodRule traverses the plan from bottom to the top and makes it difficult to check whether a variable is used after a SELECT operator. So, we need to change the rule that it starts from TOP level and collects used variables information until it sees SELECT operator. Actually, that's what I do in the index-only plan. Much of functionality is already there. And I showed Steven the link to the IntroduceSelectAccessMethodRule in Index-only plan.
Best, Taewoo On Fri, Sep 16, 2016 at 11:21 AM, Mike Carey <dtab...@gmail.com> wrote: > Ditto... > > On Sep 16, 2016 11:15 AM, "Yingyi Bu" <buyin...@gmail.com> wrote: > >> I'd like to join the discussion. >> >> Best, >> Yingyi >> >> >> >> On Fri, Sep 16, 2016 at 10:47 AM, Steven Jacobs <sjaco...@ucr.edu> wrote: >> >>> Hi, >>> I have come across an issue where retainInputs is always set to false >>> when creating an index search in the select case. This was because it was >>> previously assumed that variables before the search don't need to be kept >>> after the search. In the nonPure case, this assumption is wrong. I'm now >>> looking at two possible solution: >>> >>> 1) Add specialization for nonPure cases to set retainInputs to true >>> 2) Always set retainInputs to true. This has performance implications, >>> as well as plan changes, since now a project will be added above the index >>> search in most cases, and the index search operator will have extra fields >>> attached to it's tuples (although in general this will be only single >>> values). >>> >>> I wanted to meet with whoever is interested, to decide the best way to >>> address this. If you are interested in joining the meeting, please reply. >>> For now I'll tentatively set the meeting for Tuesday at 11 AM. >>> >>> Steven >>> >> >>
