db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bryan Pendleton (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-3603) 'IN' clause ignores valid results, incorrect qualifier handling suspected
Date Wed, 09 Apr 2008 14:00:24 GMT

    [ https://issues.apache.org/jira/browse/DERBY-3603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12587196#action_12587196
] 

Bryan Pendleton commented on DERBY-3603:
----------------------------------------

> the join on either the left or right side, causing it to be incorrectly evaluated if
it ends up on the wrong side

That's a very intriguing theory, seems quite plausible, and worth following up. Interesting!

The other thing I was thinking about is that if I change the query to just IN (1) rather
than IN (1,21), then the problem does not occur. So I was wondering if the problem
might be that Predicate.java is now comparing the two predicates as *exactly* equal,
rather than just "equal enough for sorting during optimization", and hence was seeing
the IN (1,21) predicate, at some point, as being redundant with the join criterion and
was optimizing it entirely away.

Normally, erroneously optimizing away an entire predicate would cause us to get
more results, not fewer, but in this case the IN (1,21) predicate is effectively an "OR"
clause and so if we lost it, or maybe lost one "branch" of it, the result might have
fewer rows than we expected.

However, I tried breaking the "bad" query (the one that returns 2 rows) into 2 queries, 
one with IN (1) and one with IN (21), and got the following results:
 - query stating IN (1): count = 3
 - query stating IN (21): count = 0

So rows with admin_unit_id = 21 don't appear to be relevant to the actual results of
this query. I think that probably means this theory is not worth pursuing, but I
figured I'd post it anyway in case it was useful to others.

> 'IN' clause ignores valid results, incorrect qualifier handling suspected
> -------------------------------------------------------------------------
>
>                 Key: DERBY-3603
>                 URL: https://issues.apache.org/jira/browse/DERBY-3603
>             Project: Derby
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions: 10.3.2.1, 10.4.1.1
>            Reporter: David Butterworth
>         Attachments: derbydb.tar.bz2
>
>
> Derbys' 'IN' clause is returning different results depending on which side of a joined
table
> I am doing my 'IN' comparison against. This only occurs when the number of items within
the 'IN' clause is greater then 1.
> This behaviour was also confirmed by Bryan Pendleton in this thread:
> http://mail-archives.apache.org/mod_mbox/db-derby-user/200804.mbox/%3c47FA5974.2060705@amberpoint.com%3e
> Using the test database attatched the following 2 queries produce the issue:
> ij>  select count(*) FROM spike.accounts account, spike.admin_units admin_unit,
>     spike.bookings booking
>     WHERE booking.child_id = 2 AND
>     admin_unit.admin_unit_id IN (1,21) AND
>     booking.booking_date_time_out >= 20080331000000 AND
>     booking.booking_date_time_in <= 20080406235900 AND
>     account.account_id = booking.account_id AND
>     admin_unit.admin_unit_id = account.admin_unit_id;
> 1          
> -----------
> 2          
> 1 row selected
> ij> select count(*) FROM spike.accounts account, spike.admin_units admin_unit,
>     spike.bookings booking
>     WHERE booking.child_id = 2 AND
>     account.admin_unit_id IN (1,21) AND
>     booking.booking_date_time_out >= 20080331000000 AND
>     booking.booking_date_time_in <= 20080406235900 AND
>     account.account_id = booking.account_id AND
>     admin_unit.admin_unit_id = account.admin_unit_id;
> 1          
> -----------
> 3          
> 1 row selected
> ij> 
> The only difference between the 2 statements is which side of a join the 'IN' clause
is matched against.
> Bryan performed some initial testing and stated the following:
> --------------------- SNIP ------------------------
> Interestingly, although the actual results do NOT contain any values
> for admin_unit_id = 21, if I change the query to:
>     admin_unit.admin_unit_id IN (1)
> or
>     account.admin_unit_id IN (1)
> then the problem disappears -- I get 3 rows for both queries.
> I also ran query plans for both the queries (in the IN (1,21) case)
> and have pasted the (simplified) query plans at the end of this message.
> I notice that in the case where the query gives 2 rows, which is
> when we specify admin_unit.admin_unit_id in (1,21), the admin_unit_id
> index scan output in the query plan contains:
>            qualifiers:
> Column[0][0] Id: 0
> Operator: =
> Ordered nulls: false
> Unknown return value: false
> Negate comparison result: false
> However, in the case where the query gives 3 rows, which is
> when we specify account.admin_unit_id in (1,21), the admin_unit_id
> index scan output in the query plan contains:
>            qualifiers:
> None
> I think it is the presence/absence of this qualifier on the query
> scan which is causing the different results in the query, as in
> the first case we see:
>            Number of rows qualified=2
>            Number of rows visited=3
> but in the second case we see:
>            Number of rows qualified=3
>            Number of rows visited=3
> I definitely don't have any explanation for why you are getting
> this odd behavior; it certainly seems like a bug to me.
> -------------END SNIP -----------------------

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message