ignite-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vladimir Ozerov (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (IGNITE-6663) SQL: optimize primary key equality lookup
Date Mon, 11 Dec 2017 12:57:00 GMT

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

Vladimir Ozerov edited comment on IGNITE-6663 at 12/11/17 12:56 PM:
--------------------------------------------------------------------

[~kirill.shirokov], in general fix is correct, but there are several minor issues to address:
1) Please avoid long variable and method names. They should be as compact as possible. Also
abbreviations are not allowed in methods.
{{partitionRowFilterClo()}} -> {{filter()}}
{{gridCursor}} -> {{cursor}}
{{partitionFilter}} -> {{"p"}} or {{"filter"}}
2) {{SingletonCursor}} - looks like we could reuse {{org.h2.index.SingleRowCursor}} instead
of creating our own implementation.
3) {{H2DynamicIndexAbstractSelfTest}} hosts tests for dynamic index create/drop routines only.
So it is not appropriate place for new tests for this feature. IMO {{IgniteCacheAbstractFieldsQuerySelfTest}}
should be enough.


was (Author: vozerov):
[~kirill.shirokov], in general fix is correct, but there are several minor issues to address:
1) Please avoid long variable and method names. They should be as compact as possible. Also
abbreviations are not allowed in methods.
{{partitionRowFilterClo()}} -> {{filter()}}
{{gridCursor}} -> cursor}}
{{partitionFilter}} -> {{"p"}} or {{"filter"}}
2) {{SingletonCursor}} - looks like we could reuse {{org.h2.index.SingleRowCursor}} instead
of creating our own implementation.
3) {{H2DynamicIndexAbstractSelfTest}} hosts tests for dynamic index create/drop routines only.
So it is not appropriate place for new tests for this feature. IMO {{IgniteCacheAbstractFieldsQuerySelfTest}}
should be enough.

> SQL: optimize primary key equality lookup
> -----------------------------------------
>
>                 Key: IGNITE-6663
>                 URL: https://issues.apache.org/jira/browse/IGNITE-6663
>             Project: Ignite
>          Issue Type: Task
>          Components: sql
>            Reporter: Vladimir Ozerov
>            Assignee: Kirill Shirokov
>              Labels: performance
>             Fix For: 2.4
>
>
> H2 perform every index search through {{BaseIndex.find}} method. It contains both {{first}}
and {{last}} rows. If condition looks like {{attr = ?}}, then both bounds are the same. When
this call is propagated to our {{BPlusTree}}, then two index lookups occur:
> - Lower bound: {{BPlusTree#findInsertionPoint}}
> - Upper bound: {{BPlusTree.ForwardCursor#findUpperBound}}
> This is done for a reason because we do not know in advance how many elements are in
between the bounds, so one lookup + scan is not an option in general case. But in case of
PK lookup with equality condition, when we know in advance that only one row will be returned,
this leads to additional unnecessary comparisons. 
> Suggested fix:
> 1) Make sure that all rows in {{GridH2PlainRowFactory}} has correct {{equals}} implementation.
> 2) Inside {{H2TreeIndex#find}}: if this is PK index (see constructor args) and {{lower.equals(upper)}},
then use {{BPlusTree.findOne}} instead of {{BPlusTree.find}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Mime
View raw message