[
https://issues.apache.org/jira/browse/DERBY-4357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Hillegas updated DERBY-4357:
---------------------------------
Attachment: derby-4357-03-aa-hashjoin.diff
Attaching derby-4357-03-aa-hashjoin.diff. This patch adds support for hashjoins
plus some miscellaneous cleanup.
1) It turns out that when the optimizer puts a hash table on top of a VTI, the
optimizer does not fabricate a ProjectRestrict node. This patch adds logic to
the hash table node so it pushes its search restriction into the VTI just as
the ProjectRestrict node does.
2) It also turns out that the VTI node has enough information to compute the
projection by itself. Made the computation of the projection more robust by
having the VTI compute the projection itself in cases where the parent did not
request this service.
Touches the following files:
M java/engine/org/apache/derby/impl/sql/compile/Predicate.java
Miscellaneous cleanup of the node-printing logic.
M java/engine/org/apache/derby/impl/sql/compile/HashTableNode.java
Logic supporting (1).
M java/engine/org/apache/derby/impl/sql/compile/FromVTI.java
Logic supporting (2).
M java/engine/org/apache/derby/impl/sql/compile/ProjectRestrictNode.java
Moved up the logic which pushes the VTI projection/restriction so that it is
parallel to what is done in HashTableNode.
M
java/testing/org/apache/derbyTesting/functionTests/tests/lang/IntegerArrayVTI.java
M
java/testing/org/apache/derbyTesting/functionTests/tests/lang/RestrictedVTITest.java
More tests.
> TableFunctions provide no information to limit underlying query
> ---------------------------------------------------------------
>
> Key: DERBY-4357
> URL: https://issues.apache.org/jira/browse/DERBY-4357
> Project: Derby
> Issue Type: Improvement
> Components: SQL
> Affects Versions: 10.4.1.3, 10.4.2.0, 10.5.1.1, 10.5.2.0, 10.5.3.0
> Environment: ALL
> Reporter: Chris Goodacre
> Assignee: Rick Hillegas
> Attachments: derby-4357-01-aa-publicAPI.diff,
> derby-4357-02-ac-passThrough.diff, derby-4357-02-ad-passThrough.diff,
> derby-4357-03-aa-hashjoin.diff, RestrictedTableFunctions.html,
> RestrictedTableFunctions.html, RestrictedTableFunctions.html,
> RestrictedTableFunctions.html, RestrictedTableFunctions.html
>
>
> The API specification for TableFunctions cannot provide information to the
> implementer of the TableFunction about the details of the query. For
> example:
> (a) I defined a table function named MyFunction with columns a,b, & c
> (b) I bind the table function properly using the CREATE FUNCTION SQL.
> User executes the following SQL:
> select a,b from table ( MyFunction() ) where c = 123
> Without passing the column list and/or where clause as arguments to the table
> function, my implementation can not know that it only needs two of the three
> columns, and only rows where c = 123.
> For TableFunctions that are built to integrate distant/legacy data, the cost
> of the query can be prohibitive. It would be better if information
> regarding the columns in the select and restrictions from the where clause
> could be passed to the developer.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
