Type: New Feature
Affects Version/s: BIGDATA_RELEASE_1_2_0
Fix Version/s: None
Component/s: Query Plan Generator
Per , here are some interesting breakdowns of the total time:
It looks like there is a lot of fat in the query optimization phase and perhaps in the query parser (which is known to drive the heap heavily).
A big driver of the HEAP is the iterator() methods. That is coming out of AbstractList.listIterator(), Collections$SynchronizedCollection.iterator(), AbstractSequentialList.iterator(), and ModifiableBOpBase$NotifyingList.iterator().
Some of the big drivers for those iterator methods are:
Striterator.addFilter() shows up BIG with back traces through BOpUtility$Expand, which is part of the same iteration pattern.
This suggests that we could win big if we could improve our iteration patterns over the AST.
 https://sourceforge.net/apps/trac/bigdata/ticket/546 (Index cache for Journal)