[JBoss JIRA] (TEIID-3289) Join subquery containing ifnull in join condition
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3289?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3289:
---------------------------------------
After looking at this more, it is a similar issue to TEIID-3282. The conversion of a timestamp to string (which is chosen as the common type for timestamp/integer) will slightly differ between Teiid and the pushdown equivalent for mysql (in the pushdown query above as "date_format(g_0.`RESOLUTIONDATE`, '%Y-%m-%d %H:%i:%S.%f')"). The mysql value will have all of the trailing zero fractional seconds:
Teiid: 2012-01-01 00:00:00.0
MySQL: 2012-01-01 00:00:00.000000
We do note in the documentation that there can be variations in string formatting. This makes their use in join predicates problematic when one value is computed at the source and the other is computed in Teiid. A recommended workaround would be to compare the timestamp values directly:
IFNULL(CalculatedField1_Sub.jiraissue_CREATED, {ts '0001-01-01 00:00:00'})
Other than not allowing the pushdown of the timestamp to string conversion I'm not sure there is a good code fix as simply removing trailing zeros is not enough.
> Join subquery containing ifnull in join condition
> -------------------------------------------------
>
> Key: TEIID-3289
> URL: https://issues.jboss.org/browse/TEIID-3289
> Project: Teiid
> Issue Type: Feature Request
> Reporter: Mark Tawk
> Assignee: Steven Hawkins
> Priority: Critical
>
> I have join subquery linked to main query via 2 fields in the query below.
> To be able to join null values between main query and subquery, I have added ifnull to join fields with a random value.
> If I run my query directly over mysql, the field CalculatedField1 return values whenever the field RESOLUTIONDATE is null in the main query.
> But when executed in Teiid, the query returns always null for the field CalculatedField1.
> When looking at the jdbc queries executed by Teiid, I found that ifnull is used for the main query fields but not for the subquery fields, which may be causing a link problem between main query and subquery.
> I have tried to put the ifnull into the subquery but still getting jdbc subquery fields without the ifnull function.
> SELECT DISTINCT
> jiraissue.RESOLUTIONDATE AS jiraissue_RESOLUTIONDATE,
> jiraissue.CREATED AS jiraissue_CREATED,
> CalculatedField1_Sub.CalculatedField1 AS CalculatedField1
> FROM tjiradb_D1_VDB_DSModel.tjiradb.jiraissue jiraissue
> LEFT JOIN
> (SELECT DISTINCT
> TIMESTAMPDIFF(
> SQL_TSI_MINUTE,
> jiraissue_sub.CREATED,
> PARSETIMESTAMP('2014-10-03 00:00:00',
> 'yyyy-MM-dd HH:mm:ss'))
> AS CalculatedField1,
> jiraissue_sub.RESOLUTIONDATE AS jiraissue_RESOLUTIONDATE,
> jiraissue_sub.CREATED AS jiraissue_CREATED
> FROM tjiradb_D1_VDB_DSModel.tjiradb.jiraissue jiraissue_sub
> WHERE ((((jiraissue_sub.RESOLUTIONDATE IS NULL)))))
> CalculatedField1_Sub
> ON (IFNULL(jiraissue.RESOLUTIONDATE, -2147483648) =
> IFNULL(CalculatedField1_Sub.jiraissue_RESOLUTIONDATE,
> -2147483648))
> AND (IFNULL(jiraissue.CREATED, -2147483648) =
> IFNULL(CalculatedField1_Sub.jiraissue_CREATED,
> -2147483648))
> Teiid JDBC queries:
> SELECT DISTINCT g_0.`RESOLUTIONDATE` AS c_0, g_0.`CREATED` AS c_1, ifnull(date_format(g_0.`RESOLUTIONDATE`, '%Y-%m-%d %H:%i:%S.%f'), '-2147483648') AS c_2, ifnull(date_format(g_0.`CREATED`, '%Y-%m-%d %H:%i:%S.%f'), '-2147483648') AS c_3 FROM `tjiradb`.`jiraissue` AS g_0 ORDER BY c_2, c_3
> SELECT g_0.`CREATED`, g_0.`RESOLUTIONDATE` FROM `tjiradb`.`jiraissue` AS g_0 WHERE g_0.`RESOLUTIONDATE` IS NULL
> Teiid Execution plan
>
> <?xml version='1.0' encoding='UTF-8'?><node name="LimitNode"><property name="Output Columns"><value>jiraissue_RESOLUTIONDATE (timestamp)</value><value>jiraissue_CREATED (timestamp)</value><value>CalculatedField1 (long)</value></property><property name="Statistics"><value>Node Output Rows: 10</value><value>Node Next Batch Process Time: 7</value><value>Node Cumulative Next Batch Process Time: 43</value><value>Node Cumulative Process Time: 49</value><value>Node Next Batch Calls: 4</value><value>Node Blocks: 3</value></property><property name="Cost Estimates"><value>Estimated Node Cardinality: 10.0</value></property><property name="Child 0"><node name="SortNode"><property name="Output Columns"><value>jiraissue_RESOLUTIONDATE (timestamp)</value><value>jiraissue_CREATED (timestamp)</value><value>CalculatedField1 (long)</value></property><property name="Statistics"><value>Node Output Rows: 10</value><value>Node Next Batch Process Time: 13</value><value>Node Cumulative Next Batch Process Time: 42</value><value>Node Cumulative Process Time: 48</value><value>Node Next Batch Calls: 4</value><value>Node Blocks: 3</value></property><property name="Cost Estimates"><value>Estimated Node Cardinality: -1.0</value></property><property name="Child 0"><node name="ProjectNode"><property name="Output Columns"><value>jiraissue_RESOLUTIONDATE (timestamp)</value><value>jiraissue_CREATED (timestamp)</value><value>CalculatedField1 (long)</value></property><property name="Statistics"><value>Node Output Rows: 2048</value><value>Node Next Batch Process Time: 0</value><value>Node Cumulative Next Batch Process Time: 35</value><value>Node Cumulative Process Time: 0</value><value>Node Next Batch Calls: 5</value><value>Node Blocks: 4</value></property><property name="Cost Estimates"><value>Estimated Node Cardinality: -1.0</value></property><property name="Child 0"><node name="JoinNode"><property name="Output Columns"><value>RESOLUTIONDATE (timestamp)</value><value>CREATED (timestamp)</value><value>CalculatedField1 (long)</value></property><property name="Statistics"><value>Node Output Rows: 2048</value><value>Node Next Batch Process Time: 0</value><value>Node Cumulative Next Batch Process Time: 35</value><value>Node Cumulative Process Time: 0</value><value>Node Next Batch Calls: 5</value><value>Node Blocks: 4</value></property><property name="Cost Estimates"><value>Estimated Node Cardinality: -1.0</value></property><property name="Child 0"><node name="AccessNode"><property name="Output Columns"><value>RESOLUTIONDATE (timestamp)</value><value>CREATED (timestamp)</value><value>expr (string)</value><value>expr (string)</value></property><property name="Statistics"><value>Node Output Rows: 2048</value><value>Node Next Batch Process Time: 0</value><value>Node Cumulative Next Batch Process Time: 1</value><value>Node Cumulative Process Time: 0</value><value>Node Next Batch Calls: 10</value><value>Node Blocks: 6</value></property><property name="Cost Estimates"><value>Estimated Node Cardinality: -1.0</value></property><property name="Query"><value>SELECT DISTINCT g_0.RESOLUTIONDATE AS c_0, g_0.CREATED AS c_1, IFNULL(convert(g_0.RESOLUTIONDATE, string), '-2147483648') AS c_2, IFNULL(convert(g_0.CREATED, string), '-2147483648') AS c_3 FROM tjiradb_D1_VDB_DSModel.tjiradb.jiraissue AS g_0 ORDER BY c_2, c_3</value></property><property name="Model Name"><value>tjiradb_D1_VDB_DSModel</value></property></node></property><property name="Child 1"><node name="ProjectNode"><property name="Output Columns"><value>CalculatedField1 (long)</value><value>jiraissue_RESOLUTIONDATE (timestamp)</value><value>jiraissue_CREATED (timestamp)</value><value>CalculatedField11 (long)</value><value>expr (string)</value><value>expr (string)</value></property><property name="Statistics"><value>Node Output Rows: 1320</value><value>Node Next Batch Process Time: 22</value><value>Node Cumulative Next Batch Process Time: 18</value><value>Node Cumulative Process Time: 25</value><value>Node Next Batch Calls: 4</value><value>Node Blocks: 1</value></property><property name="Child 0"><node name="ProjectNode"><property name="Output Columns"><value>CalculatedField1 (long)</value><value>jiraissue_RESOLUTIONDATE (timestamp)</value><value>jiraissue_CREATED (timestamp)</value><value>CalculatedField11 (long)</value></property><property name="Statistics"><value>Node Output Rows: 1320</value><value>Node Next Batch Process Time: 9</value><value>Node Cumulative Next Batch Process Time: 3</value><value>Node Cumulative Process Time: 10</value><value>Node Next Batch Calls: 2</value><value>Node Blocks: 1</value></property><property name="Cost Estimates"><value>Estimated Node Cardinality: -1.0</value></property><property name="Child 0"><node name="AccessNode"><property name="Output Columns"><value>CREATED (timestamp)</value><value>RESOLUTIONDATE (timestamp)</value></property><property name="Statistics"><value>Node Output Rows: 1320</value><value>Node Next Batch Process Time: 8</value><value>Node Cumulative Next Batch Process Time: 1</value><value>Node Cumulative Process Time: 8</value><value>Node Next Batch Calls: 2</value><value>Node Blocks: 1</value></property><property name="Cost Estimates"><value>Estimated Node Cardinality: -1.0</value></property><property name="Query"><value>SELECT g_0.CREATED, g_0.RESOLUTIONDATE FROM tjiradb_D1_VDB_DSModel.tjiradb.jiraissue AS g_0 WHERE g_0.RESOLUTIONDATE IS NULL</value></property><property name="Model Name"><value>tjiradb_D1_VDB_DSModel</value></property></node></property><property name="Select Columns"><value>TIMESTAMPDIFF(SQL_TSI_MINUTE, jiraissue_sub.CREATED, {ts'2014-10-03 00:00:00.0'}) AS CalculatedField1</value><value>jiraissue_sub.RESOLUTIONDATE AS jiraissue_RESOLUTIONDATE</value><value>jiraissue_sub.CREATED AS jiraissue_CREATED</value><value>TIMESTAMPDIFF(SQL_TSI_MINUTE, jiraissue_sub.CREATED, {ts'2014-10-03 00:00:00.0'}) AS CalculatedField11</value></property></node></property><property name="Select Columns"><value>CalculatedField1_Sub.CalculatedField1</value><value>CalculatedField1_Sub.jiraissue_RESOLUTIONDATE</value><value>CalculatedField1_Sub.jiraissue_CREATED</value><value>CalculatedField1_Sub.CalculatedField11</value><value>IFNULL(convert(CalculatedField1_Sub.jiraissue_RESOLUTIONDATE, string), '-2147483648')</value><value>IFNULL(convert(CalculatedField1_Sub.jiraissue_CREATED, string), '-2147483648')</value></property></node></property><property name="Join Strategy"><value>MERGE JOIN (ALREADY_SORTED/SORT_DISTINCT)</value></property><property name="Join Type"><value>LEFT OUTER JOIN</value></property><property name="Join Criteria"><value>IFNULL(convert(jiraissue.RESOLUTIONDATE, string), '-2147483648')=IFNULL(convert(CalculatedField1_Sub.jiraissue_RESOLUTIONDATE, string), '-2147483648')</value><value>IFNULL(convert(jiraissue.CREATED, string), '-2147483648')=IFNULL(convert(CalculatedField1_Sub.jiraissue_CREATED, string), '-2147483648')</value></property></node></property><property name="Select Columns"><value>jiraissue.RESOLUTIONDATE AS jiraissue_RESOLUTIONDATE</value><value>jiraissue.CREATED AS jiraissue_CREATED</value><value>CalculatedField1_Sub.CalculatedField1 AS CalculatedField1</value></property></node></property><property name="Sort Mode"><value>DUP_REMOVE</value></property></node></property><property name="Row Offset"><value>null</value></property><property name="Row Limit"><value>10</value></property></node>
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (TEIID-3296) Some criteria are missing when indexes are used on the source tables
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-3296?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration updated TEIID-3296:
-------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1185068
> Some criteria are missing when indexes are used on the source tables
> --------------------------------------------------------------------
>
> Key: TEIID-3296
> URL: https://issues.jboss.org/browse/TEIID-3296
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.2
> Reporter: Salvatore R
> Assignee: Steven Hawkins
> Priority: Blocker
> Fix For: 8.10
>
>
> The following two tables are defined in two different datasources (PostgreSQL and MySQL):
> {code:sql}
> CREATE TABLE "pg"."tx1"
> (
> a varchar(2147483647),
> b varchar(2147483647),
> c integer,
> d integer,
> e integer
> );
> CREATE INDEX tx1_b ON "pg"."tx1"(b);
> CREATE INDEX tx1_a ON "pg"."tx1"(a);
> CREATE INDEX tx1_e ON "pg"."tx1"(e);
> CREATE INDEX tx1_d ON "pg"."tx1"(d);
> CREATE INDEX tx1_c ON "pg"."tx1"(c);
>
> CREATE TABLE "my"."tx2"
> (
> a integer,
> b integer,
> c integer,
> d integer,
> e integer
> );
> insert into tx1 VALUES(1,1,1,1,1) ;
> insert into tx1 VALUES(1,2,2,2,2) ;
> insert into tx1 VALUES(1,2,3,3,3) ;
> insert into tx1 VALUES(1,2,3,4,4) ;
> insert into tx1 VALUES(1,2,3,4,5) ;
> insert into tx2 VALUES(1,2,3,4,5) ;
> {code}
> Running the following query:
> {code:sql}
> select tx1.* from pg.tx1 as tx1 join my.tx2 as tx2 on tx1.a=tx2.a and tx1.b=tx2.b and tx1.c=tx2.c and tx1.d=tx2.d and tx1.e!=tx2.e;
> {code}
> a wrong result is returned:
> ||a||b||c||d||e||
> |1|2|2|2|2|
> |1|2|3|3|3|
> |1|2|3|4|4|
> If indexes are removed from the source table, the expected result is correctly returned:
> ||a||b||c||d||e||
> |1|2|3|4|4|
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (TEIID-3272) JDBC Translator | Segregation of batch execution and commit mode
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3272?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-3272.
-----------------------------------
Resolution: Rejected
Control of batch commit as written in this enhancement is not something that we can pursue.
A related and potentially valid approach would be to allow the use of source connections in a more directly controlled local transaction mode. This would look something like not automatically starting a global transaction on a Teiid client local transaction and tracking connections via transaction on the server side. With the issue of course that when using multiple sources the commits will not be coordinated.
> JDBC Translator | Segregation of batch execution and commit mode
> -----------------------------------------------------------------
>
> Key: TEIID-3272
> URL: https://issues.jboss.org/browse/TEIID-3272
> Project: Teiid
> Issue Type: Enhancement
> Components: JDBC Connector
> Reporter: Shiveeta Mattoo
> Assignee: Steven Hawkins
> Labels: Batch-Commit, JDBC-Transator
> Attachments: batch1.png
>
>
> In JDBC Translator, the batch execution and commit are coupled together. Hence, we after every batch execution, a commit is executed.
> This enhancement is for providing an ability to support the commit after a configurable 'x' no. of batches has completed, instead of an automatic commit after every batch.
> The no of batches after which a commit is desired should be a configurable option.
>
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (TEIID-3298) invokeHttp procedure should support returning HTTP Response Code
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-3298?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-3298:
-------------------------------------
JSON sounds good, may be we can just post a parsing routine along with it, so that we establish the parsing routine
> invokeHttp procedure should support returning HTTP Response Code
> ----------------------------------------------------------------
>
> Key: TEIID-3298
> URL: https://issues.jboss.org/browse/TEIID-3298
> Project: Teiid
> Issue Type: Enhancement
> Components: Misc. Connectors
> Affects Versions: 8.4
> Reporter: Ramesh Reddy
> Assignee: Steven Hawkins
>
> Currently WS Translator supplied "invokeHttp" procedure only returns the result and as well as the content-type. It should also return response code.
> It may be useful to check if there is any other return parameters can be useful too. Like cookie etc.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (TEIID-3296) Some criteria are missing when indexes are used on the source tables
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3296?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-3296:
----------------------------------
Priority: Blocker (was: Major)
> Some criteria are missing when indexes are used on the source tables
> --------------------------------------------------------------------
>
> Key: TEIID-3296
> URL: https://issues.jboss.org/browse/TEIID-3296
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.2
> Reporter: Salvatore R
> Assignee: Steven Hawkins
> Priority: Blocker
> Fix For: 8.10
>
>
> The following two tables are defined in two different datasources (PostgreSQL and MySQL):
> {code:sql}
> CREATE TABLE "pg"."tx1"
> (
> a varchar(2147483647),
> b varchar(2147483647),
> c integer,
> d integer,
> e integer
> );
> CREATE INDEX tx1_b ON "pg"."tx1"(b);
> CREATE INDEX tx1_a ON "pg"."tx1"(a);
> CREATE INDEX tx1_e ON "pg"."tx1"(e);
> CREATE INDEX tx1_d ON "pg"."tx1"(d);
> CREATE INDEX tx1_c ON "pg"."tx1"(c);
>
> CREATE TABLE "my"."tx2"
> (
> a integer,
> b integer,
> c integer,
> d integer,
> e integer
> );
> insert into tx1 VALUES(1,1,1,1,1) ;
> insert into tx1 VALUES(1,2,2,2,2) ;
> insert into tx1 VALUES(1,2,3,3,3) ;
> insert into tx1 VALUES(1,2,3,4,4) ;
> insert into tx1 VALUES(1,2,3,4,5) ;
> insert into tx2 VALUES(1,2,3,4,5) ;
> {code}
> Running the following query:
> {code:sql}
> select tx1.* from pg.tx1 as tx1 join my.tx2 as tx2 on tx1.a=tx2.a and tx1.b=tx2.b and tx1.c=tx2.c and tx1.d=tx2.d and tx1.e!=tx2.e;
> {code}
> a wrong result is returned:
> ||a||b||c||d||e||
> |1|2|2|2|2|
> |1|2|3|3|3|
> |1|2|3|4|4|
> If indexes are removed from the source table, the expected result is correctly returned:
> ||a||b||c||d||e||
> |1|2|3|4|4|
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (TEIID-3298) invokeHttp procedure should support returning HTTP Response Code
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3298?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3298:
---------------------------------------
There is quite of bit of information that could be useful. Adding an out parameter for each is possible. Other approaches would be to have a resultset with name value pair columns (which could be cumbersome to use) or a json value (since we lack a map construct).
> invokeHttp procedure should support returning HTTP Response Code
> ----------------------------------------------------------------
>
> Key: TEIID-3298
> URL: https://issues.jboss.org/browse/TEIID-3298
> Project: Teiid
> Issue Type: Enhancement
> Components: Misc. Connectors
> Affects Versions: 8.4
> Reporter: Ramesh Reddy
> Assignee: Steven Hawkins
>
> Currently WS Translator supplied "invokeHttp" procedure only returns the result and as well as the content-type. It should also return response code.
> It may be useful to check if there is any other return parameters can be useful too. Like cookie etc.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (TEIID-3290) Auto generated REST WAR truncates the larger payloads
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-3290?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration updated TEIID-3290:
-------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1185024
> Auto generated REST WAR truncates the larger payloads
> -----------------------------------------------------
>
> Key: TEIID-3290
> URL: https://issues.jboss.org/browse/TEIID-3290
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 8.4
> Reporter: Ramesh Reddy
> Assignee: Ramesh Reddy
>
> Currently only query parameters are supported as the input parameters to the Teiid procedure in POST based call.
> The POST BODY also needs to be supported to handle larger payloads in this situation as query parameters has size limitations. Currently string based query parameters are supported, but since they passed as is as strings on larger payloads the they will be subject 4000 string length restriction.
> It should be possible to read metadata of the procedure and convert the string objects to respective objects before the query gets executed.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (TEIID-3296) Some criteria are missing when indexes are used on the source tables
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3296?page=com.atlassian.jira.plugin... ]
Steven Hawkins edited comment on TEIID-3296 at 1/22/15 11:38 AM:
-----------------------------------------------------------------
Added predicates containing non-column reference expressions to be preserved. This needs to be queued for 8.7.x
was (Author: shawkins):
Added predicates containing non-column reference expressions to be preserved.
> Some criteria are missing when indexes are used on the source tables
> --------------------------------------------------------------------
>
> Key: TEIID-3296
> URL: https://issues.jboss.org/browse/TEIID-3296
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.2
> Reporter: Salvatore R
> Assignee: Steven Hawkins
> Fix For: 8.10
>
>
> The following two tables are defined in two different datasources (PostgreSQL and MySQL):
> {code:sql}
> CREATE TABLE "pg"."tx1"
> (
> a varchar(2147483647),
> b varchar(2147483647),
> c integer,
> d integer,
> e integer
> );
> CREATE INDEX tx1_b ON "pg"."tx1"(b);
> CREATE INDEX tx1_a ON "pg"."tx1"(a);
> CREATE INDEX tx1_e ON "pg"."tx1"(e);
> CREATE INDEX tx1_d ON "pg"."tx1"(d);
> CREATE INDEX tx1_c ON "pg"."tx1"(c);
>
> CREATE TABLE "my"."tx2"
> (
> a integer,
> b integer,
> c integer,
> d integer,
> e integer
> );
> insert into tx1 VALUES(1,1,1,1,1) ;
> insert into tx1 VALUES(1,2,2,2,2) ;
> insert into tx1 VALUES(1,2,3,3,3) ;
> insert into tx1 VALUES(1,2,3,4,4) ;
> insert into tx1 VALUES(1,2,3,4,5) ;
> insert into tx2 VALUES(1,2,3,4,5) ;
> {code}
> Running the following query:
> {code:sql}
> select tx1.* from pg.tx1 as tx1 join my.tx2 as tx2 on tx1.a=tx2.a and tx1.b=tx2.b and tx1.c=tx2.c and tx1.d=tx2.d and tx1.e!=tx2.e;
> {code}
> a wrong result is returned:
> ||a||b||c||d||e||
> |1|2|2|2|2|
> |1|2|3|3|3|
> |1|2|3|4|4|
> If indexes are removed from the source table, the expected result is correctly returned:
> ||a||b||c||d||e||
> |1|2|3|4|4|
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (TEIID-3296) Some criteria are missing when indexes are used on the source tables
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3296?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-3296:
----------------------------------
Fix Version/s: 8.10
Affects Version/s: 8.2
Component/s: Query Engine
Forum Reference: https://developer.jboss.org/message/916717
The fix from TEIID-2190 was incomplete. This should have been addressed at that time.
> Some criteria are missing when indexes are used on the source tables
> --------------------------------------------------------------------
>
> Key: TEIID-3296
> URL: https://issues.jboss.org/browse/TEIID-3296
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.2
> Reporter: Salvatore R
> Assignee: Steven Hawkins
> Fix For: 8.10
>
>
> The following two tables are defined in two different datasources (PostgreSQL and MySQL):
> {code:sql}
> CREATE TABLE "pg"."tx1"
> (
> a varchar(2147483647),
> b varchar(2147483647),
> c integer,
> d integer,
> e integer
> );
> CREATE INDEX tx1_b ON "pg"."tx1"(b);
> CREATE INDEX tx1_a ON "pg"."tx1"(a);
> CREATE INDEX tx1_e ON "pg"."tx1"(e);
> CREATE INDEX tx1_d ON "pg"."tx1"(d);
> CREATE INDEX tx1_c ON "pg"."tx1"(c);
>
> CREATE TABLE "my"."tx2"
> (
> a integer,
> b integer,
> c integer,
> d integer,
> e integer
> );
> insert into tx1 VALUES(1,1,1,1,1) ;
> insert into tx1 VALUES(1,2,2,2,2) ;
> insert into tx1 VALUES(1,2,3,3,3) ;
> insert into tx1 VALUES(1,2,3,4,4) ;
> insert into tx1 VALUES(1,2,3,4,5) ;
> insert into tx2 VALUES(1,2,3,4,5) ;
> {code}
> Running the following query:
> {code:sql}
> select tx1.* from pg.tx1 as tx1 join my.tx2 as tx2 on tx1.a=tx2.a and tx1.b=tx2.b and tx1.c=tx2.c and tx1.d=tx2.d and tx1.e!=tx2.e;
> {code}
> a wrong result is returned:
> ||a||b||c||d||e||
> |1|2|2|2|2|
> |1|2|3|3|3|
> |1|2|3|4|4|
> If indexes are removed from the source table, the expected result is correctly returned:
> ||a||b||c||d||e||
> |1|2|3|4|4|
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (TEIID-3296) Some criteria are missing when indexes are used on the source tables
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3296?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-3296.
-----------------------------------
Resolution: Done
Added predicates containing non-column reference expressions to be preserved.
> Some criteria are missing when indexes are used on the source tables
> --------------------------------------------------------------------
>
> Key: TEIID-3296
> URL: https://issues.jboss.org/browse/TEIID-3296
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.2
> Reporter: Salvatore R
> Assignee: Steven Hawkins
> Fix For: 8.10
>
>
> The following two tables are defined in two different datasources (PostgreSQL and MySQL):
> {code:sql}
> CREATE TABLE "pg"."tx1"
> (
> a varchar(2147483647),
> b varchar(2147483647),
> c integer,
> d integer,
> e integer
> );
> CREATE INDEX tx1_b ON "pg"."tx1"(b);
> CREATE INDEX tx1_a ON "pg"."tx1"(a);
> CREATE INDEX tx1_e ON "pg"."tx1"(e);
> CREATE INDEX tx1_d ON "pg"."tx1"(d);
> CREATE INDEX tx1_c ON "pg"."tx1"(c);
>
> CREATE TABLE "my"."tx2"
> (
> a integer,
> b integer,
> c integer,
> d integer,
> e integer
> );
> insert into tx1 VALUES(1,1,1,1,1) ;
> insert into tx1 VALUES(1,2,2,2,2) ;
> insert into tx1 VALUES(1,2,3,3,3) ;
> insert into tx1 VALUES(1,2,3,4,4) ;
> insert into tx1 VALUES(1,2,3,4,5) ;
> insert into tx2 VALUES(1,2,3,4,5) ;
> {code}
> Running the following query:
> {code:sql}
> select tx1.* from pg.tx1 as tx1 join my.tx2 as tx2 on tx1.a=tx2.a and tx1.b=tx2.b and tx1.c=tx2.c and tx1.d=tx2.d and tx1.e!=tx2.e;
> {code}
> a wrong result is returned:
> ||a||b||c||d||e||
> |1|2|2|2|2|
> |1|2|3|3|3|
> |1|2|3|4|4|
> If indexes are removed from the source table, the expected result is correctly returned:
> ||a||b||c||d||e||
> |1|2|3|4|4|
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months