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 <[email protected]> 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 <[email protected]> > 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 > > >
