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 > > >
