[
https://issues.apache.org/jira/browse/GEODE-730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15139390#comment-15139390
]
ASF subversion and git services commented on GEODE-730:
-------------------------------------------------------
Commit d232e25947a8e223f35feb1feffe3150875dc5f5 in incubator-geode's branch
refs/heads/develop from [~huynhja]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=d232e25 ]
GEODE-730: Optimize single filter join queries
When executing a join query with additional filters on a single region, we now
detect this scenario and
instead of creating a CompositeGroupJunction, we create a regular
GroupJunction. When we being cutdown
and expansion, we then create new compiled comparisons so that we can do an
index lookup.
For example "select * from /region1 a, /region2 b where a.name = "joe" and a.id
= b.id"
We will now execute the a.name first assuming an index is present on a.name
During cutdown and expand, we determine that the comparison a.id = b.id can
create a new compiled comparison
because the alias a from a.id matches our original filter a.name. We can
evaluate a.id at this point, say id
evaluated to 8. So we create a compiled comparison of b.id = 8. We can now do
a lookup using the index on b.id.
We retrieve these results and place them into a map. This map will be used to
continue to derive additional joins
if they exist. Such as b.id = c.id, etc...
We can continue with the iteration but instead of iterating the entire b
region, we can now go over derived results.
This also includes a fix to not unlock an index lock when reevaluating an inner
query.
> Optimize single filter join queries
> -----------------------------------
>
> Key: GEODE-730
> URL: https://issues.apache.org/jira/browse/GEODE-730
> Project: Geode
> Issue Type: Bug
> Components: querying
> Reporter: Jason Huynh
> Assignee: Jason Huynh
>
> Currently single filter join queries create a lot of garbage and do the join
> before pruning from the filter. We can optimize this for specific cases to
> prune prior to joining and only join values that have already passed the
> filters.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
