asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Taewoo Kim <wangs...@gmail.com>
Subject Re: Primary key lookup plan
Date Mon, 04 Dec 2017 00:08:57 GMT
>From Line 531
https://github.com/apache/asterixdb/blob/master/asterixdb/asterix-algebra/src/main/java/org/apache/asterix/optimizer/rules/am/BTreeAccessMethod.java


Best,
Taewoo

On Sun, Dec 3, 2017 at 4:05 PM, Taewoo Kim <wangsaeu@gmail.com> wrote:

> My understanding is that if a select condition can be covered by the
> primary key (i.e., only contains the primary key condition and B+Tree can
> be utilized), then only unnest-map should survive.
>
>
> Best,
> Taewoo
>
> On Sun, Dec 3, 2017 at 4:03 PM, Chen Luo <cluo8@uci.edu> wrote:
>
>> I don't think it's the case...I tried on my local env, and it's using a
>> primary index lookup instead of scan. Can you make sure the spelling of
>> the
>> primary key is correct?
>>
>> On Sun, Dec 3, 2017 at 3:49 PM, Wail Alkowaileet <wael.y.k@gmail.com>
>> wrote:
>>
>> > Hi Devs,
>> >
>> > *For the given query:*
>> >
>> > SELECT VALUE t.text
>> > FROM ITweets as t
>> > WHERE t.tid = 100
>> >
>> > *The optimized plan:*
>> >
>> > distribute result [$$6]
>> > -- DISTRIBUTE_RESULT  |PARTITIONED|
>> >   exchange
>> >   -- ONE_TO_ONE_EXCHANGE  |PARTITIONED|
>> >     project ([$$6])
>> >     -- STREAM_PROJECT  |PARTITIONED|
>> >       assign [$$6] <- [$$t.getField("text")]
>> >       -- ASSIGN  |PARTITIONED|
>> >         project ([$$t])
>> >         -- STREAM_PROJECT  |PARTITIONED|
>> >           select (eq($$7, 100))
>> >           -- STREAM_SELECT  |PARTITIONED|
>> >             exchange
>> >             -- ONE_TO_ONE_EXCHANGE  |PARTITIONED|
>> >               data-scan []<-[$$7, $$t] <- FlatDataverse.ITweets
>> >               -- DATASOURCE_SCAN  |PARTITIONED|
>> >                 exchange
>> >                 -- ONE_TO_ONE_EXCHANGE  |PARTITIONED|
>> >                   empty-tuple-source
>> >                   -- EMPTY_TUPLE_SOURCE  |PARTITIONED|
>> >
>> > Do we always do a scan and then filter the result, even though the query
>> > predicate is on the primary key?
>> > --
>> >
>> > *Regards,*
>> > Wail Alkowaileet
>> >
>>
>
>

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