db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bergquist, Brett" <BBergqu...@canoga.com>
Subject Re: Should the optimizer ever have a cost of "0.0"?
Date Tue, 27 Aug 2013 17:14:51 GMT
Here is one case where the cost can become 0.0.   This is from FromBaseTable.java:

			** Let the join strategy decide whether the cost of the base
			** scan is a single scan, or a scan per outer row.
			** NOTE: The multiplication should only be done against the
			** total row count, not the singleScanRowCount.
			double newCost = costEstimate.getEstimatedCost();

			if (currentJoinStrategy.multiplyBaseCostByOuterRows())
				newCost *= outerCost.rowCount();

				costEstimate.rowCount() * outerCost.rowCount(),

So if the outer table optimization determines that there are no rows (incorrectly) then the
newCost is going to end up being 0.0 even though this table cost might be very large (ie.
a table scan of a table with many rows).   

On Aug 27, 2013, at 12:46 PM, mike matrigali <mikemapp1@gmail.com> wrote:

> On 8/27/2013 9:43 AM, Rick Hillegas wrote:
>> On 8/27/13 8:18 AM, Bergquist, Brett wrote:
>>> I am just wondering if while the optimizer is producing a plan if a
>>> cost of "0.0" should ever be seen.  Thinking naively, it seems to me
>>> that all join plans and all access paths have some sort of cost which
>>> should be greater than "0.0".   From my testing over the last few
>>> days, when a plan comes up with a join such as "join T1 with T2" and
>>> the T1 cost is "0.0", then this dominates the plan cost and even if
>>> T2's access path is going to be a table scan of millions of rows, this
>>> plan might be chosen.   This just does not seem right to me.
>> Hi Brett,
>> A scan cost of 0 sounds like a bug to me.
>> Thanks,
>> -Rick
> I agree, seems like even a 0 row return scan should have some cost.

View raw message