[
https://issues.apache.org/jira/browse/DERBY-2641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12496049
]
A B commented on DERBY-2641:
----------------------------
> I would say it is reasonable to expect a table scan in these cases since the
> table only contains one row, but
> I don't know enough about this area to say whether it's a bug. If someone
> thinks it's a bug, I will file a JIRA
> for it.
I took a quick look at this and noticed the following comment in the
"estimateCost(...)" method of FromBaseTable:
/* we prefer index than table scan for concurrency reason, by a small
* adjustment on estimated row count. This affects optimizer's decision
* especially when few rows are in table. beetle 5006. This makes sense
* since the plan may stay long before we actually check and invalidate it.
* And new rows may be inserted before we check and invalidate the plan.
* Here we only prefer index that has start/stop key from predicates. Non-
* constant start/stop key case is taken care of by selectivity later.
*/
I think this why the optimizer is choosing an index scan. It seems
intentional, so my guess is that this is *not* a bug. Probably the case that
the comments in statelplans.sql were not updated when the above comment (and
associated code) was added...?
> Convert lang/staleplans.sql to JUnit
> ------------------------------------
>
> Key: DERBY-2641
> URL: https://issues.apache.org/jira/browse/DERBY-2641
> Project: Derby
> Issue Type: Improvement
> Components: Test
> Affects Versions: 10.3.0.0
> Reporter: Knut Anders Hatlen
> Assigned To: Knut Anders Hatlen
> Priority: Minor
> Attachments: derby-2641-1.diff, derby-2641-1.stat
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
