[
https://issues.apache.org/jira/browse/DERBY-6301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13884719#comment-13884719
]
Mamta A. Satoor commented on DERBY-6301:
----------------------------------------
I looked at InListMultiProbeTest and found following comment about how to
determine from query plan if multi-probe is being used.
* We determine that "multi-probing" was in effect by looking at
* the query plan and verifying two things:
*
* 1. We used an IndexRowToBaseRow ResultSet on the target
* table, AND
* 2. We did an index scan on the target table AND
* 3. The number of rows that "qualified" is equal to the
* number of rows that were actually returned for the query.
* If we did *not* do multi-probing then we would scan all or
* part of the index and then apply the IN-list restriction
* after reading the rows. That means that the number of
* rows "qualified" for the scan would be greater than the
* number of rows returned from the query. But if we do
* multi-probing we will probe for rows that we know satsify
* the restriction, thus the number of rows that we "fetch"
* (i.e. "rows qualified") should exactly match the number
* of rows in the result set.
> 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.5#6160)
