[jira] [Commented] (ASTERIXDB-1905) Filter doesn't created correct if create index using bulkload

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/ASTERIXDB-1905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 
Tested-by: Jenkins 
BAD: Jenkins 
Integration-Tests: Jenkins 
Reviewed-by: Jianfeng Jia 


> 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)

[jira] [Commented] (ASTERIXDB-1905) Filter doesn't created correct if create index using bulkload

[Ian Maxon (JIRA)]

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

Ian Maxon commented on ASTERIXDB-1905:
--

Seems like the type is right on compile but is lost somewhere on execution

> 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)