asterixdb-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ASTERIXDB-1905) Filter doesn't created correct if create index using bulkload
Date Tue, 16 May 2017 18:59:04 GMT

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

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

Commit 9861cbfb710c7bf1c72a19923ad3413d938c90cd in asterixdb's branch refs/heads/master from
[~imaxon]
[ https://git-wip-us.apache.org/repos/asf?p=asterixdb.git;h=9861cbf ]

ASTERIXDB-1905: Incorrect filter for post-load sidx

The issue seems to be limited to RTrees. The MBR evaluators
were not accounting for the point MBR optimization as they
were in the compiled load pidx+sidx case

Change-Id: Iea158ad4c29ad4421020a28a72e68637bc538560
Reviewed-on: https://asterix-gerrit.ics.uci.edu/1743
Sonar-Qube: Jenkins <jenkins@fulliautomatix.ics.uci.edu>
Tested-by: Jenkins <jenkins@fulliautomatix.ics.uci.edu>
BAD: Jenkins <jenkins@fulliautomatix.ics.uci.edu>
Integration-Tests: Jenkins <jenkins@fulliautomatix.ics.uci.edu>
Reviewed-by: Jianfeng Jia <jianfeng.jia@gmail.com>


> Filter doesn't created correct if create index using bulkload
> -------------------------------------------------------------
>
>                 Key: ASTERIXDB-1905
>                 URL: https://issues.apache.org/jira/browse/ASTERIXDB-1905
>             Project: Apache AsterixDB
>          Issue Type: Bug
>            Reporter: Jianfeng Jia
>            Assignee: Ian Maxon
>            Priority: Blocker
>
> It seems we are not passing the correct(or enough) information to the secondary index
BulkloadOperator when it is created afterward if the data has been ingested already. During
the bulkload, only the secondary keys are sent to the index, while the filter information
is pointed to the first value of the next secondary keys, which makes the filter information
incorrect. 
> We actually have several test cases for it, e.g., `filters/load-with-secondary-rtree`.
However, the test is passed just by chance. Since the filter type tag is *double* (comes from
the first key of the secondary keys), and the search query is *datetime* , and the filter
satisfies function will only call the rawComparator by comparing the first byte, which always
matches *index.filterValue < query.filterValue* .  And we happened to choose the *$m.send-time
< datetime("2012-11-20T10:10:00.000Z")* query. If we choose the *>* relation, then nothing
is returned. 
> I mark it *blocking* because first it's a correctness problem, and it's also blocking
my *pass-2ndary-filter-to-primary*  patch. Thanks for the help!



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Mime
View raw message