db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-4357) TableFunctions provide no information to limit underlying query
Date Fri, 30 Oct 2009 18:23:59 GMT

     [ 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.


Mime
View raw message