dynamobi/dynamobi — Issue #142: [LDB-180] LucidDB costing does not take into consideration row widths
Author: dynamobi-build
Created: 2011-12-30 02:16:48+00:00
State: open
Labels: LDB, Optimizer

[reporter="zfong", created="Wed, 20 Aug 2008 15:17:14 -0500 (GMT-05:00)"]
RelMetadataQuery.getCumulativeCost returns a RelOptCost, which includes 3 components -- # rows, CPU, and I/O. However, the variations of this method defined in LoptMetadataProvider, which are used by LucidDB, only make use of the # rows component.

This can be problematic if you're dealing with tables that have a large number of columns. You incur additional I/O and data transfer cost when reading and passing around wider data rows so even though two query plans are identical in terms of number of rows processed, one may be more costly than the other because of a higher data transfer volume.

Ideally, the number of columns accessed should factor into the CPU and I/O costs, as is currently done in LcsRowScanRelBase.computeCost. Note that this is partially being addressed in LucidDB by a more localized change that uses column widths only to break ties between two plans when they have the same cost in terms of # rows processed. However, if we do generalize things by taking into account all 3 components, then as part of that, we need to decide what constitutes a lower cost. I.e., do all 3 components have to be smaller, or only 2 out of 3, or some weighted sum of the 3?