July 2018 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-5421) Regression with enhanced sort join performance

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-5421?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-5421. ----------------------------------- Resolution: Done Fully checking the relative sizes when considering building a right side index. The test case added for TEIID-5422 shows an improvement by rejecting building the index. > Regression with enhanced sort join performance > ---------------------------------------------- > > Key: TEIID-5421 > URL: https://issues.jboss.org/browse/TEIID-5421 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 9.3 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 11.1 > > > A regression was introduced in 9.3 with enhanced sort join performance over moderately large row sets. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5420) Costing can over estimate join cardinality when no keys nor ndv is specified

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-5420?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-5420. ----------------------------------- Resolution: Done Changed to a simpler assumption to use high ndv for the side of the join that is more unique. > Costing can over estimate join cardinality when no keys nor ndv is specified > ---------------------------------------------------------------------------- > > Key: TEIID-5420 > URL: https://issues.jboss.org/browse/TEIID-5420 > Project: Teiid > Issue Type: Quality Risk > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 11.1, 11.0.1 > > > The changes from TEIID-4885 allow for joins lacking all but cardinality information to have their cardinality over-estimated. The estimate should be made more cautious by default as that would be the most common case. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5422) Buffer cleaner running too often in some cases

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-5422?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-5422. ----------------------------------- Resolution: Done Changed the interval to 5 seconds (more than twice the default timeslice of 2 seconds) which shows a great improvement in the performance test checked in with this issue, but no degradation in the other performance tests. > Buffer cleaner running too often in some cases > ---------------------------------------------- > > Key: TEIID-5422 > URL: https://issues.jboss.org/browse/TEIID-5422 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 11.1, 11.0.1, 10.3.3 > > > As observed in TEIID-5418 when the buffer cleaner runs too often it causes thrashing by pushing out pages that get reused close to the cleaning interval of 100 milliseconds. > Increasing that interval to at least beyond the default time-slice will consume more heap - but the cleaner will still be engaged when a processing thread must clean beyond the max allowed. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5422) Buffer cleaner running too often in some cases

by Steven Hawkins (JIRA)

Steven Hawkins created TEIID-5422: ------------------------------------- Summary: Buffer cleaner running too often in some cases Key: TEIID-5422 URL: https://issues.jboss.org/browse/TEIID-5422 Project: Teiid Issue Type: Bug Components: Query Engine Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 11.1, 11.0.1, 10.3.3 As observed in TEIID-5418 when the buffer cleaner runs too often it causes thrashing by pushing out pages that get reused close to the cleaning interval of 100 milliseconds. Increasing that interval to at least beyond the default time-slice will consume more heap - but the cleaner will still be engaged when a processing thread must clean beyond the max allowed. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5420) Costing can over estimate join cardinality when no keys nor ndv is specified

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-5420?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-5420: ---------------------------------- Fix Version/s: 11.0.1 > Costing can over estimate join cardinality when no keys nor ndv is specified > ---------------------------------------------------------------------------- > > Key: TEIID-5420 > URL: https://issues.jboss.org/browse/TEIID-5420 > Project: Teiid > Issue Type: Quality Risk > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 11.1, 11.0.1 > > > The changes from TEIID-4485 allow for joins lacking all but cardinality information to have their cardinality over-estimated. The estimate should be made more cautious by default as that would be the most common case. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5420) Costing can over estimate join cardinality when no keys nor ndv is specified

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-5420?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-5420: ---------------------------------- Description: The changes from TEIID-4885 allow for joins lacking all but cardinality information to have their cardinality over-estimated. The estimate should be made more cautious by default as that would be the most common case. (was: The changes from TEIID-4485 allow for joins lacking all but cardinality information to have their cardinality over-estimated. The estimate should be made more cautious by default as that would be the most common case.) > Costing can over estimate join cardinality when no keys nor ndv is specified > ---------------------------------------------------------------------------- > > Key: TEIID-5420 > URL: https://issues.jboss.org/browse/TEIID-5420 > Project: Teiid > Issue Type: Quality Risk > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 11.1, 11.0.1 > > > The changes from TEIID-4885 allow for joins lacking all but cardinality information to have their cardinality over-estimated. The estimate should be made more cautious by default as that would be the most common case. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5421) Regression with enhanced sort join performance

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-5421?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-5421: --------------------------------------- I'm seeing two related issues. The first is that TEIID-5017 allows for some joins to be processed sub-optimally - the avoidance of buffering is causing more work by searching an index that is too large. A follow on issue that is probably not directly related is that running a reproducer for the case described by TEIID-5417 repeatedly shows that as more of the materialization is pushed out of the heap memory space performance significantly drops. > Regression with enhanced sort join performance > ---------------------------------------------- > > Key: TEIID-5421 > URL: https://issues.jboss.org/browse/TEIID-5421 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 9.3 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 11.1 > > > A regression was introduced in 9.3 with enhanced sort join performance over moderately large row sets. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5421) Regression with enhanced sort join performance

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-5421?page=com.atlassian.jira.plugin... ] Steven Hawkins edited comment on TEIID-5421 at 7/17/18 2:04 PM: ---------------------------------------------------------------- I'm seeing two issues. The first is that TEIID-5017 allows for some joins to be processed sub-optimally - the avoidance of buffering is causing more work by searching an index that is too large. A follow on issue that is probably not directly related is that running a reproducer for the case described by TEIID-5417 repeatedly shows that as more of the materialization is pushed out of the heap memory space performance significantly drops. was (Author: shawkins): I'm seeing two related issues. The first is that TEIID-5017 allows for some joins to be processed sub-optimally - the avoidance of buffering is causing more work by searching an index that is too large. A follow on issue that is probably not directly related is that running a reproducer for the case described by TEIID-5417 repeatedly shows that as more of the materialization is pushed out of the heap memory space performance significantly drops. > Regression with enhanced sort join performance > ---------------------------------------------- > > Key: TEIID-5421 > URL: https://issues.jboss.org/browse/TEIID-5421 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 9.3 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 11.1 > > > A regression was introduced in 9.3 with enhanced sort join performance over moderately large row sets. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5421) Regression with enhanced sort join performance

by Steven Hawkins (JIRA)

Steven Hawkins created TEIID-5421: ------------------------------------- Summary: Regression with enhanced sort join performance Key: TEIID-5421 URL: https://issues.jboss.org/browse/TEIID-5421 Project: Teiid Issue Type: Bug Components: Query Engine Affects Versions: 9.3 Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 11.1 A regression was introduced in 9.3 with enhanced sort join performance over moderately large row sets. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5397) Make RETURN_GENERATED_KEYS work with views

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-5397?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-5397: ---------------------------------- Fix Version/s: 11.1 Summary: Make RETURN_GENERATED_KEYS work with views (was: RETURN_GENERATED_KEYS not working) > Make RETURN_GENERATED_KEYS work with views > ------------------------------------------ > > Key: TEIID-5397 > URL: https://issues.jboss.org/browse/TEIID-5397 > Project: Teiid > Issue Type: Feature Request > Affects Versions: 10.2.1 > Reporter: Lukáš Svačina > Assignee: Steven Hawkins > Fix For: 11.1 > > > *+VDB:+* > {code} > <vdb name="_GENERATED_form_shoes" version="2"> > <model name="_INTERNAL_internalModel" type="PHYSICAL"> > <source name="internal_postgresql" translator-name="postgresql" connection-jndi-name="java:/internal"/> > </model> > <model name="GEN_view" type="VIRTUAL"> > <metadata type="DDL"> > <![CDATA[ CREATE VIEW "_view_workflow_data" OPTIONS (UPDATABLE 'true') > AS SELECT "public"."form_shoes_2"."size" AS "size", "public"."form_shoes_2"."model" AS "model", > "public"."form_shoes_2"."id" AS "id" FROM "public"."form_shoes_2" ]]> > </metadata> > </model> > </vdb> > {code} > *+TABLE:+* > name: form_shoes_2 > columns: id (SERIAL) | size (INTEGER *NULLABLE*) | model (VARCHAR *NULLABLE*) > *+PROBLEM:+* > Connected into VDB using JDBC like: > {code:java} > final PreparedStatement statement = c.prepareStatement(...INSERT..., Statement.RETURN_GENERATED_KEYS); > statement.executeUpdate(); > final ResultSet generatedKeys = statement.getGeneratedKeys(); > {code} > *generatedKeys is empty if:* > # INSERT INTO "form_shoes_2" ( "model" ) VALUES ( 'adidas x1' ) ...... e.g. not all columns are enumerated ... if so, you can provide NULL values to optional columns and generated keys WORK! > # INSERT INTO "_view_workflow_data" (id, name, size) VALUES (42, 'adidas x2', 12 ) ....... e.g. insering into view (1:1, no joins involved) even when all columns ARE enumerated ... probably no way how to get generated keys here? > *+QUESTIONS:+* > # How to get last_insert_id() when inserting into foreign table/views (with/without joins)? > # How to get updated rows (UPDATE ... RETURNING *)? At least primary keys of affected rows? > Thanks for fixing/adding this functionality. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues July 2018