[jira] [Commented] (ASTERIXDB-2966) Non-equijoin in probe w/ array index gives different result

["ASF subversion and git services (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/ASTERIXDB-2966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17418919#comment-17418919 ] 

ASF subversion and git services commented on ASTERIXDB-2966:
------------------------------------------------------------

Commit a42e6669f77eea38a1c5697b31520f8c39f7ec70 in asterixdb's branch refs/heads/master from ggalvizo
[ https://gitbox.apache.org/repos/asf?p=asterixdb.git;h=a42e666 ]

[ASTERIXDB-2966][IDX] Disabling array index INLJ for non-equjoins in probe

- user model changes: no
- storage format changes: no
- interface changes: no

If there are non-equijoins in the probe (which lead to NL joins),
disable INLJ acceleration from array indexes. This is a broader scope
than the cross-joins in the probe from the previous fix.

Change-Id: I0d36784272acc43f4eb4d876d8f6ebe07b8014ff
Reviewed-on: https://asterix-gerrit.ics.uci.edu/c/asterixdb/+/13303
Integration-Tests: Jenkins <je...@fulliautomatix.ics.uci.edu>
Tested-by: Jenkins <je...@fulliautomatix.ics.uci.edu>
Reviewed-by: Dmitry Lychagin <dm...@couchbase.com>


> Non-equijoin in probe w/ array index gives different result
> -----------------------------------------------------------
>
>                 Key: ASTERIXDB-2966
>                 URL: https://issues.apache.org/jira/browse/ASTERIXDB-2966
>             Project: Apache AsterixDB
>          Issue Type: Bug
>          Components: IDX - Indexes
>            Reporter: Glenn Justo Galvizo
>            Assignee: Glenn Justo Galvizo
>            Priority: Major
>
> *Found with RQG
> The following query gives different results when the array index compiler flag is raised.
> {code:java}
> FROM ProbeDataset1 AS D2,
> ProbeDataset2 AS D3,
> IndexedDataset AS D1
> WHERE ( SOME AND EVERY V1 IN D1.container_object_2.nesting_1.contained_object_1 SATISFIES ( V1.double_rand_4.contained_object_1 /* +indexnl */ >= (TO_DOUBLE(D3.integer_rand_4) + 0.5) ) )
> SELECT COUNT(*);{code}
> The problem seems to be with non-equijoins in the probe. This issue does not arise if we were to switch the order of the two probes (eliminating the join in the probe). I speculate it has something to do with the rewrites involved in producing non-hash joins in the probe.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)