[JBoss JIRA] (TEIID-2728) Very large sorts are inefficient
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2728?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-2728:
----------------------------------
Fix Version/s: 8.4.1
> Very large sorts are inefficient
> --------------------------------
>
> Key: TEIID-2728
> URL: https://issues.jboss.org/browse/TEIID-2728
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.4
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 8.4.1, 8.6
>
>
> This is a regression of TEIID-2429. When the memory space needed for a sort is estimated to be above 2 GB, the expression used (even though it's assigned to a long) will overflow. This then causes the processing to use the batch size as the intermediate sort buffer size, which for any high row count will lead to many passes (the logic typically should achieve at most a two pass sort).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 1 month
[JBoss JIRA] (TEIID-2728) Very large sorts are inefficient
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2728?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-2728.
-----------------------------------
Resolution: Done
Corrected the potential overflow and adjusted the 2/3 pass sort index calculation which could lead to an extra pass.
> Very large sorts are inefficient
> --------------------------------
>
> Key: TEIID-2728
> URL: https://issues.jboss.org/browse/TEIID-2728
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.4
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 8.6
>
>
> This is a regression of TEIID-2429. When the memory space needed for a sort is estimated to be above 2 GB, the expression used (even though it's assigned to a long) will overflow. This then causes the processing to use the batch size as the intermediate sort buffer size, which for any high row count will lead to many passes (the logic typically should achieve at most a two pass sort).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 1 month
[JBoss JIRA] (TEIID-2721) Resolving an aliased view prevents inherent update from working
by Johnathon Lee (JIRA)
[ https://issues.jboss.org/browse/TEIID-2721?page=com.atlassian.jira.plugin... ]
Johnathon Lee updated TEIID-2721:
---------------------------------
Fix Version/s: 7.7.9
> Resolving an aliased view prevents inherent update from working
> ---------------------------------------------------------------
>
> Key: TEIID-2721
> URL: https://issues.jboss.org/browse/TEIID-2721
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 7.7
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Critical
> Fix For: 8.4.1, 8.6, 7.7.9
>
> Attachments: 2721-77x.patch
>
>
> If an aliased form of an inherently updatable view is resolved first, we will cache invalid update info which prevents inherent insert/update from functioning correctly.
> For example with the view gx, first running:
> select * from gx as x
>
> will prevent an inherent insert such as:
> insert into gx (e1, e2, e3, e4) select * from pm1.g1
> from working as expected
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 1 month