Hi Vishal,
I think, we need both solution 1 & 2
Solution1 may need re-desiging several parts of Carbon's query process
starting from scanner, aggregator to result preparation. This can help
avoid the frequent cache invalidation.
In Solution2 code generation will not solve the frequent cache inva
Hi Vishal,
In general, it is good idea to have a cache efficient algorithm.
For solution-1 : how do you want to handle variable length columns and
nulls? may be you will have to maintain variable length columns separately
and use offsets ?
For solution 2: code generation may be more efficient
Hi Jacky,
Yes result preparation in exeutor side.
-Regards
Kumar Vishal
On Wed, Oct 12, 2016 at 9:33 PM, Jacky Li wrote:
> Hi Vishal,
>
> Which part of the preparation are you considering? The column stitching in
> the executor side?
>
> Regards,
> Jacky
>
> > 在 2016年10月12日，下午9:24，Kumar Vishal
Hi Vishal,
Which part of the preparation are you considering? The column stitching in the
executor side?
Regards,
Jacky
> 在 2016年10月12日，下午9:24，Kumar Vishal 写道：
>
> Hi All,
> Currently we are preparing the final result row wise, as number of columns
> present in project list(80 columns) is hig
Hi All,
Currently we are preparing the final result row wise, as number of columns
present in project list(80 columns) is high mainly measure column or no
dictionary column there are lots of cpu cache invalidation is happening and
this is resulting to slower the query performance.
*I can think of
