asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Taewoo Kim <>
Subject Re: Retain inputs on index-search
Date Fri, 16 Sep 2016 18:26:00 GMT
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.


On Fri, Sep 16, 2016 at 11:21 AM, Mike Carey <> wrote:

> Ditto...
> On Sep 16, 2016 11:15 AM, "Yingyi Bu" <> wrote:
>> I'd like to join the discussion.
>> Best,
>> Yingyi
>> On Fri, Sep 16, 2016 at 10:47 AM, Steven Jacobs <> 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

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