I will plan to work through Taewoo's idea unless there are objections. I
think it won't be too much of a "hack" since the code is needed for the
index-only plan as well, and it will not be nonPure-specific.
Steven

On Friday, September 16, 2016, Taewoo Kim <wangs...@gmail.com> wrote:

> 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
> <javascript:_e(%7B%7D,'cvml','dtab...@gmail.com');>> wrote:
>
>> Ditto...
>>
>> On Sep 16, 2016 11:15 AM, "Yingyi Bu" <buyin...@gmail.com
>> <javascript:_e(%7B%7D,'cvml','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
>>> <javascript:_e(%7B%7D,'cvml','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
>>>>
>>>
>>>
>

Reply via email to