asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Carey <>
Subject Re: Retain inputs on index-search
Date Fri, 16 Sep 2016 20:08:16 GMT
Cool - let's break out that bit of logic and maybe do that as a separate 

On 9/16/16 11:34 AM, Steven Jacobs wrote:
> 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 <> 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 <
>> <javascript:_e(%7B%7D,'cvml','');>> wrote:
>>> Ditto...
>>> On Sep 16, 2016 11:15 AM, "Yingyi Bu" <
>>> <javascript:_e(%7B%7D,'cvml','');>> wrote:
>>>> I'd like to join the discussion.
>>>> Best,
>>>> Yingyi
>>>> On Fri, Sep 16, 2016 at 10:47 AM, Steven Jacobs <
>>>> <javascript:_e(%7B%7D,'cvml','');>> 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
>>>>> previously assumed that variables before the search don't need to be
>>>>> after the search. In the nonPure case, this assumption is wrong. I'm
>>>>> 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
>>>>> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message