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 00:05:39 GMT
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
> >
>

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