[
https://issues.apache.org/jira/browse/DERBY-6301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13804606#comment-13804606
]
Rick Hillegas commented on DERBY-6301:
--------------------------------------
Hi Mike,
I wasn't involved in implementing multi-probe, so I will need some education
here. I have a couple questions:
1) Is the multi-probe strategy picked for any query other than one involving an
IN list?
2) You say that there is a bound on the number of IN list items allowed in a
multi-probe strategy. It seems that you are suggesting that there should also
be a bound on the number of OR clauses which are pushed down into the Store.
How are those two bounds different?
Thanks,
-Rick
> SQL layer should push down IN list predicates to store when doing a scan
> ------------------------------------------------------------------------
>
> Key: DERBY-6301
> URL: https://issues.apache.org/jira/browse/DERBY-6301
> Project: Derby
> Issue Type: Improvement
> Components: SQL
> Affects Versions: 10.10.1.1
> Reporter: Mike Matrigali
>
> The store interface allows for OR and AND qualifiers to be passed down to
> store as part of either
> a heap or btree scan. It is more efficient to qualify the rows at the lowest
> levels. The SQL level
> does not seem to push any qualifier in the case of IN lists.
> This does not matter if the optimizer choses the multi-probe execution
> strategy for the IN list as that also
> qualifies the row at the lowest level.
> The problem arises when the optimizer chooses not to do multi-probe, for
> instance if it determines there
> are too many terms in the in-list relative to the size of the table and the
> cardinality of the terms. In this
> case it chooses a scan with no qualifiers which results in all rows being
> returned to the sql layer and qualified there.
> In addition to performance considerations this presents a locking problem
> with respect to the repeatable read isolation level. It is optimal in
> repeatable read to not maintain locks on those
> rows that do not qualify. Currently this locking optimization only takes
> place for those rows that
> are qualified in the store vs. those qualified in the upper SQL layer. So in
> the case of a non-multi-probe IN-LIST plan all non-qualified rows looked at
> as part of the execution will remain locked in repeatable
> read.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
