Got it. Best, Taewoo
On Sun, Dec 3, 2017 at 5:15 PM, Wail Alkowaileet <[email protected]> wrote: > INT to BIGINT seems to work fine. > > The primary key type I have is a string (I was testing my rewrite rules) so > i didn't pay attention to the type difference, and I was wondering why the > select op is there. > > On Dec 3, 2017 16:36, "Taewoo Kim" <[email protected]> wrote: > > > Hm... type-casting should happen in that case. You are saying providing > an > > INT to BIGINT primary index? > > > > Best, > > Taewoo > > > > On Sun, Dec 3, 2017 at 4:20 PM, Wail Alkowaileet <[email protected]> > > wrote: > > > > > Got the issue... > > > if the primary key type is not compatible with the predicate type ... > it > > > turns into a scan. > > > > > > Thanks Taewoo! > > > > > > On Sun, Dec 3, 2017 at 4:08 PM, Taewoo Kim <[email protected]> wrote: > > > > > > > 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 <[email protected]> > 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 <[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 > > > > >> > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > *Regards,* > > > Wail Alkowaileet > > > > > >
