[jira] [Commented] (IGNITE-3999) Support case insensitive search in SQL
[
https://issues.apache.org/jira/browse/IGNITE-3999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16429255#comment-16429255
]
Amir Akhmedov commented on IGNITE-3999:
---
[~NIzhikov], I fixed the comments except one, left a response in Upsource.
Can you please check my changes and let me know?
Thanks!
> Support case insensitive search in SQL
> --
>
> Key: IGNITE-3999
> URL: https://issues.apache.org/jira/browse/IGNITE-3999
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 1.7
>Reporter: Valentin Kulichenko
>Assignee: Amir Akhmedov
>Priority: Critical
> Labels: sql-engine
> Fix For: 2.5
>
>
> Currently case insensitive search is possible only with the help of
> {{lower()}} function:
> {code}
> select name from MyValue where lower(name) = 'abc_5'
> {code}
> But this will always be a full scan, even if {{name}} field is indexed.
> We need to correctly support {{VARCHAR_IGNORECASE}} H2 type in Ignite and add
> a respective property to {{@QuerySqlField}} annotation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7812) Slow rebalancing in case of enabled persistence
[ https://issues.apache.org/jira/browse/IGNITE-7812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16429252#comment-16429252 ] Joel Lang commented on IGNITE-7812: --- I've found that this happens after page eviction begins for the cache. It seems to be related to file reads in PageMemoryImpl.acquirePage() as a result of the H2 query index being updated when new rows are received during rebalancing. The segment write lock is held during these read operations which dramatically slows down other operations. It was a crippling slowdown in my test case which was done on a development VM which uses a HDD, not a SSD. We would be looking at 1-2 days of rebalance time for a cache with 6 million entries and 2 indexes in t hat case. Fortunately, it seems as if this has already been fixed for 2.5, the disk read happens after the segment write lock is released now: [PageMemoryImpl.java#L750|https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/pagemem/PageMemoryImpl.java#L750] > Slow rebalancing in case of enabled persistence > --- > > Key: IGNITE-7812 > URL: https://issues.apache.org/jira/browse/IGNITE-7812 > Project: Ignite > Issue Type: Task >Reporter: Alexey Goncharuk >Assignee: Pavel Kovalenko >Priority: Major > > A user reported that rebalancing take significantly larger amounts of time > when persistence is enabled even in LOG_ONLY mode. > Need to investigate how the performance of rebalancing may be increased. > Also, it would be great to estimate the benefit of file transfer for > rebalancing. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-7812) Slow rebalancing in case of enabled persistence
[ https://issues.apache.org/jira/browse/IGNITE-7812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16429252#comment-16429252 ] Joel Lang edited comment on IGNITE-7812 at 4/7/18 6:01 AM: --- I've found that this happens after page eviction begins for the cache. It seems to be related to file reads in PageMemoryImpl.acquirePage(), primarily as a result of the H2 query index being updated when new rows are received during rebalancing. The segment write lock is held during these read operations which dramatically slows down other operations. It was a crippling slowdown in my test case which was done on a development VM which uses a HDD, not a SSD. We would be looking at 1-2 days of rebalance time for a cache with 6 million entries and 2 indexes in t hat case. Fortunately, it seems as if this has already been fixed for 2.5, the disk read happens after the segment write lock is released now: [PageMemoryImpl.java#L750|https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/pagemem/PageMemoryImpl.java#L750] was (Author: langj): I've found that this happens after page eviction begins for the cache. It seems to be related to file reads in PageMemoryImpl.acquirePage() as a result of the H2 query index being updated when new rows are received during rebalancing. The segment write lock is held during these read operations which dramatically slows down other operations. It was a crippling slowdown in my test case which was done on a development VM which uses a HDD, not a SSD. We would be looking at 1-2 days of rebalance time for a cache with 6 million entries and 2 indexes in t hat case. Fortunately, it seems as if this has already been fixed for 2.5, the disk read happens after the segment write lock is released now: [PageMemoryImpl.java#L750|https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/pagemem/PageMemoryImpl.java#L750] > Slow rebalancing in case of enabled persistence > --- > > Key: IGNITE-7812 > URL: https://issues.apache.org/jira/browse/IGNITE-7812 > Project: Ignite > Issue Type: Task >Reporter: Alexey Goncharuk >Assignee: Pavel Kovalenko >Priority: Major > > A user reported that rebalancing take significantly larger amounts of time > when persistence is enabled even in LOG_ONLY mode. > Need to investigate how the performance of rebalancing may be increased. > Also, it would be great to estimate the benefit of file transfer for > rebalancing. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-7812) Slow rebalancing in case of enabled persistence
[ https://issues.apache.org/jira/browse/IGNITE-7812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16429252#comment-16429252 ] Joel Lang edited comment on IGNITE-7812 at 4/7/18 6:02 AM: --- I've found that this happens after page eviction begins for the cache. It seems to be related to file reads in PageMemoryImpl.acquirePage(), primarily as a result of the H2 query index being updated when new rows are received during rebalancing. The segment write lock is held during these read operations which dramatically slows down other operations. It was a crippling slowdown in my test case (50x or more) which was done on a development VM which uses a HDD, not a SSD. We would be looking at 1-2 days of rebalance time for a cache with 6 million entries and 2 indexes in that case. While we do plan to use a SSD for production, this is still an excessive slowdown. Fortunately, it seems as if this has already been fixed for 2.5, the disk read happens after the segment write lock is released now: [PageMemoryImpl.java#L750|https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/pagemem/PageMemoryImpl.java#L750] was (Author: langj): I've found that this happens after page eviction begins for the cache. It seems to be related to file reads in PageMemoryImpl.acquirePage(), primarily as a result of the H2 query index being updated when new rows are received during rebalancing. The segment write lock is held during these read operations which dramatically slows down other operations. It was a crippling slowdown in my test case (50x or more) which was done on a development VM which uses a HDD, not a SSD. We would be looking at 1-2 days of rebalance time for a cache with 6 million entries and 2 indexes in t hat case. Fortunately, it seems as if this has already been fixed for 2.5, the disk read happens after the segment write lock is released now: [PageMemoryImpl.java#L750|https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/pagemem/PageMemoryImpl.java#L750] > Slow rebalancing in case of enabled persistence > --- > > Key: IGNITE-7812 > URL: https://issues.apache.org/jira/browse/IGNITE-7812 > Project: Ignite > Issue Type: Task >Reporter: Alexey Goncharuk >Assignee: Pavel Kovalenko >Priority: Major > > A user reported that rebalancing take significantly larger amounts of time > when persistence is enabled even in LOG_ONLY mode. > Need to investigate how the performance of rebalancing may be increased. > Also, it would be great to estimate the benefit of file transfer for > rebalancing. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-7812) Slow rebalancing in case of enabled persistence
[ https://issues.apache.org/jira/browse/IGNITE-7812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16429252#comment-16429252 ] Joel Lang edited comment on IGNITE-7812 at 4/7/18 6:02 AM: --- I've found that this happens after page eviction begins for the cache. It seems to be related to file reads in PageMemoryImpl.acquirePage(), primarily as a result of the H2 query index being updated when new rows are received during rebalancing. The segment write lock is held during these read operations which dramatically slows down other operations. It was a crippling slowdown in my test case (50x or more) which was done on a development VM which uses a HDD, not a SSD. We would be looking at 1-2 days of rebalance time for a cache with 6 million entries and 2 indexes in t hat case. Fortunately, it seems as if this has already been fixed for 2.5, the disk read happens after the segment write lock is released now: [PageMemoryImpl.java#L750|https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/pagemem/PageMemoryImpl.java#L750] was (Author: langj): I've found that this happens after page eviction begins for the cache. It seems to be related to file reads in PageMemoryImpl.acquirePage(), primarily as a result of the H2 query index being updated when new rows are received during rebalancing. The segment write lock is held during these read operations which dramatically slows down other operations. It was a crippling slowdown in my test case which was done on a development VM which uses a HDD, not a SSD. We would be looking at 1-2 days of rebalance time for a cache with 6 million entries and 2 indexes in t hat case. Fortunately, it seems as if this has already been fixed for 2.5, the disk read happens after the segment write lock is released now: [PageMemoryImpl.java#L750|https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/pagemem/PageMemoryImpl.java#L750] > Slow rebalancing in case of enabled persistence > --- > > Key: IGNITE-7812 > URL: https://issues.apache.org/jira/browse/IGNITE-7812 > Project: Ignite > Issue Type: Task >Reporter: Alexey Goncharuk >Assignee: Pavel Kovalenko >Priority: Major > > A user reported that rebalancing take significantly larger amounts of time > when persistence is enabled even in LOG_ONLY mode. > Need to investigate how the performance of rebalancing may be increased. > Also, it would be great to estimate the benefit of file transfer for > rebalancing. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-5874) Store TTL expire times in B+ tree on per-partition basis
[ https://issues.apache.org/jira/browse/IGNITE-5874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16429531#comment-16429531 ] Andrew Mashenkov commented on IGNITE-5874: -- TC tests looks good. > Store TTL expire times in B+ tree on per-partition basis > > > Key: IGNITE-5874 > URL: https://issues.apache.org/jira/browse/IGNITE-5874 > Project: Ignite > Issue Type: Improvement > Components: cache, persistence >Affects Versions: 2.1 >Reporter: Ivan Rakov >Assignee: Andrew Mashenkov >Priority: Major > Fix For: 2.5 > > Attachments: IgnitePdsWithTtlTest.java > > > TTL expire times for entries are stored in PendingEntriesTree, which is > singleton for cache. When expiration occurs, all system threads iterate > through the tree in order to remove expired entries. Iterating through single > tree causes contention and perfomance loss. > Related performance issue: https://issues.apache.org/jira/browse/IGNITE-5793 > We should keep instance of PendingEntriesTree for each partition, like we do > for CacheDataTree. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7877) Improve code style in GA part
[ https://issues.apache.org/jira/browse/IGNITE-7877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16429548#comment-16429548 ] Turik Campbell commented on IGNITE-7877: [~chief], - Updated. Please review. > Improve code style in GA part > - > > Key: IGNITE-7877 > URL: https://issues.apache.org/jira/browse/IGNITE-7877 > Project: Ignite > Issue Type: Improvement > Components: ml >Reporter: Yury Babak >Assignee: Turik Campbell >Priority: Minor > Fix For: 2.5 > > > Not all code in which located in genetic package follows your code style. > That should be fixed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-7877) Improve code style in GA part
[ https://issues.apache.org/jira/browse/IGNITE-7877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16429548#comment-16429548 ] Turik Campbell edited comment on IGNITE-7877 at 4/7/18 10:41 PM: - [~chief], - Updated. Please review. was (Author: netmille): [~chief], - Updated. Please review. > Improve code style in GA part > - > > Key: IGNITE-7877 > URL: https://issues.apache.org/jira/browse/IGNITE-7877 > Project: Ignite > Issue Type: Improvement > Components: ml >Reporter: Yury Babak >Assignee: Turik Campbell >Priority: Minor > Fix For: 2.5 > > > Not all code in which located in genetic package follows your code style. > That should be fixed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
