use of org.voltdb.compiler.DatabaseEstimates.TableEstimates in project voltdb by VoltDB.
the class SeqScanPlanNode method computeCostEstimates.
@Override
public void computeCostEstimates(long childOutputTupleCountEstimate, DatabaseEstimates estimates, ScalarValueHints[] paramHints) {
if (m_isSubQuery) {
// Get estimates from the sub-query
// @TODO For the sub-query the cost estimates will be calculated separately
// At the moment its contribution to the parent's cost plan is irrelevant because
// all parent plans have the same best cost plan for the sub-query
m_estimatedProcessedTupleCount = SUBQUERY_TABLE_ESTIMATES_HACK.minTuples;
m_estimatedOutputTupleCount = SUBQUERY_TABLE_ESTIMATES_HACK.minTuples;
return;
}
Table target = ((StmtTargetTableScan) m_tableScan).getTargetTable();
TableEstimates tableEstimates = estimates.getEstimatesForTable(target.getTypeName());
// This maxTuples value estimates the number of tuples fetched from the sequential scan.
// It's a vague measure of the cost of the scan.
// Its accuracy depends a lot on what kind of post-filtering or projection needs to happen, if any.
// The tuplesRead value is also used to estimate the number of RESULT rows, regardless of
// how effective post-filtering might be -- as if all rows passed the filters.
// This is at least semi-consistent with the ignoring of post-filter effects in IndexScanPlanNode.
// In effect, though, it gives index scans an "unfair" advantage when they reduce the estimated result size
// by taking into account the indexed filters -- follow-on plan steps, sorts (etc.), are costed lower
// as if they are operating on fewer rows than would have come out of the seqscan,
// though that's nonsense.
// In any case, it's important to keep an eye on any changes (discounts) to SeqScanPlanNode's costing
// here to make sure that SeqScanPlanNode never gains an unfair advantage over IndexScanPlanNode.
m_estimatedProcessedTupleCount = tableEstimates.maxTuples;
m_estimatedOutputTupleCount = tableEstimates.maxTuples;
}
Aggregations