[
https://issues.apache.org/jira/browse/DRILL-2395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14350992#comment-14350992
]
Jason Altekruse commented on DRILL-2395:
----------------------------------------
Another issue with the current evaluation model is that constant values that
require allocating an off heap buffer (such as varchar or varbinary literals)
are allocating a new buffer for the execution of the expression on each record.
I believe the work to make sure literals are only materialized once should
subsume this, but it should be noted that when this other work is done to
optimize execution on a full record batch, we should make sure no excessive
memory is being allocated for each record processed.
> Improve interpreted expression evaluation to only call the setup method once
> per batch
> --------------------------------------------------------------------------------------
>
> Key: DRILL-2395
> URL: https://issues.apache.org/jira/browse/DRILL-2395
> Project: Apache Drill
> Issue Type: Improvement
> Components: Functions - Drill
> Reporter: Jason Altekruse
> Assignee: Jason Altekruse
> Priority: Minor
>
> This enhancement request came out of the review for a patch for DRILL-2060.
> Copied below is the discussion from there:
> Jinfeng:
> Do you have a plan to move setup() call into places such that setup() will be
> called once for each VectorAccessible input?
> In the code compile + evaluation model, doSetup() will be called per batch,
> in stead of per row.
> Jason:
> I have started working on a fix for this. Its a little complicated with
> setting constant inputs before the setup method is called. I'm trying to
> figure out the best way to share code with the rest of the input passing used
> in the EvalVisitor. Would you be okay with this being opened as an
> enhancement request to be merged a little later? Considering the current use
> of the interpreter this won't have an impact on any actual queries today.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
