[jira] [Commented] (TRAFODION-2645) MDAM costing overestimates I/O cost

["ASF GitHub Bot (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/TRAFODION-2645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16189844#comment-16189844 ] 

ASF GitHub Bot commented on TRAFODION-2645:
-------------------------------------------

Github user asfgit closed the pull request at:

    https://github.com/apache/incubator-trafodion/pull/1246


> MDAM costing overestimates I/O cost
> -----------------------------------
>
>                 Key: TRAFODION-2645
>                 URL: https://issues.apache.org/jira/browse/TRAFODION-2645
>             Project: Apache Trafodion
>          Issue Type: Bug
>          Components: sql-cmp
>    Affects Versions: 2.2-incubating
>         Environment: All
>            Reporter: David Wayne Birdsall
>            Assignee: David Wayne Birdsall
>
> The method MDAMCostWA::compute (optimizer/ScanOptimizer.cpp) has logic to calculate the total cost of an MDAM plan and compare it to the cost of a single subset plan. In the case of a Trafodion table, the cost logic for MDAM cost has an error. It is adding the total number of probes (totalRqsts) to the number of seeks (totalSeeks) in order to calculate I/O costs.
> TotalSeeks models direct access disk seeks. These happen at the block level and are an I/O cost.
> TotalRqsts models the number of probes, which is a CPU cost. A probe is a direct access within a block that has already been read into memory. This is a vastly smaller unit of cost than an I/O operation.
> Note that TotalRqsts is already modeled as a message cost since it is added to TotalRows.
> The effect of the bug is to vastly penalize MDAM plans having large numbers of probes. This will show up the most on the largest tables.
> The fix is simply not to add totalRqsts to totalSeeks. However, in making this fix, it is likely that other MDAM-related parameters will need tuning. So this change needs to be done carefully.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)