The expression:

_fkProjects = 79 AND _SleepUntil IS NULL  OR _SleepUntil <= CURRENT_DATE()

is PARTIALLY-OPTIMIZED, covers 216 rows or index keys, costs 43977 bytes, and
will be applied to the Calls table (Calls) before any joins

I have indices for both _fkProjects and _SleepUntil - why is it only partially optimised?


Roy Lambert

Roy,

<< The expression:

_fkProjects = 79 AND _SleepUntil IS NULL OR _SleepUntil <= CURRENT_DATE()

is PARTIALLY-OPTIMIZED, covers 216 rows or index keys, costs 43977 bytes,
and will be applied to the Calls table (Calls) before any joins

I have indices for both _fkProjects and _SleepUntil - why is it only
partially optimised? >>

It's the cost optimizer again - it is basically optimizing the expression to
make it faster with just one index scan and then a row scan.

BTW, ElevateDB does away with the "optimized", "un-optimized", etc.
nomenclature in favor of straight-forward filter and SQL plans that explain
exactly what the optimizer is doing.  That removes the confusion when the
optimizer does something like it did here.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim


So really it should say "I de-optimised the query to make it faster" <vbcg>

Roy Lambert

Roy,

<< So really it should say "I de-optimised the query to make it faster"
<vbcg> >>

Yes. Unfortunately, it can't say it that way at this time, so it has to say
it the only way it can.

--
Tim Young
Elevate Software
www.elevatesoft.com