[
https://issues.apache.org/jira/browse/IMPALA-11972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Riza Suminto resolved IMPALA-11972.
-----------------------------------
Fix Version/s: Impala 4.4.0
Target Version: Impala 4.4.0
Resolution: Duplicate
This will be resolved in more general way by
[IMPALA-12657|http://issues.apache.org/jira/browse/IMPALA-12657].
> Factor in row width during ProcessingCost calculation.
> ------------------------------------------------------
>
> Key: IMPALA-11972
> URL: https://issues.apache.org/jira/browse/IMPALA-11972
> Project: IMPALA
> Issue Type: Improvement
> Components: Frontend
> Affects Versions: Impala 4.3.0
> Reporter: Riza Suminto
> Assignee: Riza Suminto
> Priority: Major
> Fix For: Impala 4.4.0
>
>
> IMPALA-11604 add ProcessingCost (PC) concept to measure the cost for a
> distinct PlanNode / DataSink / PlanFragment to process its input rows
> globally across all of its instances.
> We should investigate if the row width should be considered in computing PC
> for more operators, and if that will make the PC model more accurate. The
> code in IMPALA-11604 has materialization cost parameter to accommodate PC
> where row width should factor in. Currently, PC of ScanNode, ExchangeNode,
> and DataStreamSink has row width factored in through materialization
> parameter here.
> For VARCHAR, we can use some kind of average width stats, if available. For
> fixed width columns, we just use the width. In both cases, the unit should be
> in bytes. The idea of including a width in costing is to make the outcome as
> precise and less error-prone as possible.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
