This ASTERIXDB-159 <https://issues.apache.org/jira/browse/ASTERIXDB-159> maybe a good place to start with, this was recently fixed.
On Sat, Oct 1, 2016 at 10:13 PM, Yingyi Bu <[email protected]> wrote: > Wail, > > Can you attach the query plan for query 1? > I tried > count( for $x in dataset beers > return $x > ) > > and got the following plan, which seems OK: > -- DISTRIBUTE_RESULT |UNPARTITIONED| > exchange > -- ONE_TO_ONE_EXCHANGE |UNPARTITIONED| > aggregate [$$5] <- [function-call: asterix:agg-sum, Args:[%0->$$8]] > -- AGGREGATE |UNPARTITIONED| > exchange > -- RANDOM_MERGE_EXCHANGE |PARTITIONED| > aggregate [$$8] <- [function-call: asterix:agg-count, > Args:[%0->$$0]] > -- AGGREGATE |PARTITIONED| > project ([$$0]) > -- STREAM_PROJECT |PARTITIONED| > exchange > -- ONE_TO_ONE_EXCHANGE |PARTITIONED| > data-scan []<-[$$6, $$0, $$7] <- Default:beers > -- DATASOURCE_SCAN |PARTITIONED| > exchange > -- ONE_TO_ONE_EXCHANGE |PARTITIONED| > empty-tuple-source > -- EMPTY_TUPLE_SOURCE |PARTITIONED| > > > Best, > Yingyi > > On Sat, Oct 1, 2016 at 9:25 AM, Mike Carey <[email protected]> wrote: > > > Sounds like there is a new materialization bug there..... Please file a > > JIRA issue (and we'll need a query plan test case to keep it from > breaking > > again). > > > > > > > > On 10/1/16 2:01 AM, Wail Alkowaileet wrote: > > > >> Hi, > >> > >> I know that early projections will enhance the performance. > >> I just noticed something: > >> > >> 1- returning the whole tuple > >> count( for $x in dataset Tweets > >> return $x > >> ) > >> > >> => Throws an exception Java heap exceeded. (The heap-size is less than > the > >> sum of AsterixDB configured memory ... so it's not a problem). > >> > >> 2- However, returning one field > >> count( for $x in dataset Tweets > >> return $x.id > >> ) > >> > >> => Worked just fine. > >> > >> I'm just wondering, does the projection in count() affects its > >> performance ? > >> > > > > >
