Re: Primary key lookup plan

2017-12-03 Thread Taewoo Kim 
Got it.

Best,
Taewoo

On Sun, Dec 3, 2017 at 5:15 PM, Wail Alkowaileet  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"  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 
> > 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  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 
> 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  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@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
> > > > >> >
> > > > >>
> > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > >
> > > *Regards,*
> > > Wail Alkowaileet
> > >
> >
>

Re: Primary key lookup plan

2017-12-03 Thread Wail Alkowaileet 
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  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  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  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 
> >> 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

Re: Primary key lookup plan

2017-12-03 Thread Taewoo Kim 
>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  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  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 
>> 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
>> >
>>
>
>

Re: Primary key lookup plan

2017-12-03 Thread Taewoo Kim 
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  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 
> 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
> >
>

Re: Primary key lookup plan

2017-12-03 Thread Chen Luo 
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  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
>

Primary key lookup plan

2017-12-03 Thread Wail Alkowaileet 
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