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 01:20:23 GMT
Got it.

Best,
Taewoo

On Sun, Dec 3, 2017 at 5:15 PM, Wail Alkowaileet <wael.y.k@gmail.com> 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" <wangsaeu@gmail.com> 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 <wael.y.k@gmail.com>
> > 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 <wangsaeu@gmail.com> 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 <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
> > > > >> >
> > > > >>
> > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > >
> > > *Regards,*
> > > Wail Alkowaileet
> > >
> >
>

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