You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@calcite.apache.org by "Julian Hyde (JIRA)" <ji...@apache.org> on 2015/06/25 19:34:05 UTC
[jira] [Created] (CALCITE-772) Rewrite scan-filter as
scan-filter-join on sorted materialization
Julian Hyde created CALCITE-772:
-----------------------------------
Summary: Rewrite scan-filter as scan-filter-join on sorted materialization
Key: CALCITE-772
URL: https://issues.apache.org/jira/browse/CALCITE-772
Project: Calcite
Issue Type: Bug
Reporter: Julian Hyde
Assignee: Julian Hyde
If there is a sort-project materialization (think of a secondary index) then Calcite should rewrite a scan-filter query on the base table to a scan-filter on the materialization followed by a join to the base table.
This may not sound efficient, but if the join is implemented by a key scan then it is efficient. This is what Oracle calls "TABLE ACCESS BY INDEX ROWID". It may not even look like a join - it may look like a table scan that reads a sequence of row keys from an underlying relational expression.
For example, given the following schema (in pseudo-DDL):
{code}
CREATE TABLE Emp (empid, deptno, gender)
PRIMARY KEY (empid)
SORTED ON (empid);
CREATE MATERIALIZATION I_Emp_Deptno
PRIMARY KEY (deptno, empno)
SORTED ON (deptno, empno) AS
SELECT deptno, empid FROM Emp ORDER BY deptno;
{code}
Calcite should rewrite the query
{code}
SELECT * FROM Emp WHERE deptno IN (10, 20)
{code}
to
{noformat}
Join(inner, left.empno = right.empno)
Filter(deptno IN (10, 20))
TableScan(table=[I_Emp_Deptno])
TableScan(table=[Emp])
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)