[
https://issues.apache.org/jira/browse/CALCITE-2812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16754129#comment-16754129
]
Ruben Quesada Lopez edited comment on CALCITE-2812 at 1/28/19 4:43 PM:
-----------------------------------------------------------------------
I'm working on an approach inspired by [this
thread|http://mail-archives.apache.org/mod_mbox/calcite-dev/201712.mbox/%3CCAPSgeESFyih9_hf9=uMWFN00BCR7sjf0T+FRY2=ary3ygm1...@mail.gmail.com%3E]
and the implementation of 'WITH RECURSIVE' in PostgreSQL ([more
info|https://www.postgresql.org/docs/11/queries-with.html]). The key points are:
- New operators RecursiveUnion and DeltaTableScan:
-- Logical ones: LogicalRecursiveUnion, LogicalDeltaTableScan
-- Naive implementation in enumerable convention: EnumerableRecursiveUnion,
EnumerableDeltaTableScan
-- Corresponding rules to transform logical into enumerable
EnumerableRecursiveUnionRule, EnumerableDeltaTableScanRule
- The RecursiveUnion will represent a union of a recursive query, and will
have 2 inputs: a non-recursive term (aka seed) + a recursive term. Its
evaluation will be as follows:
-- Initially, the seed will be processed, and its results will be placed in a
temporary location, as they will be used as initial input for the recursive
part (see DeltaTableScan description below)
-- Then, the recursive term will be processed, and its results will be placed
in the temporary location, as they will be used as the input for the next
iteration. This process will continue until the recursive term is finished.
- The DeltaTableScan will represent an auxiliary scan, not from a real table,
but the data generated by the recursive union: initially it will read the
result of the seed and then it will read the result of the previous iteration
of the recursive term, until no new result is generated.
TODOs:
- As a first implementation, the consumer-producer communication between
RecursiveUnion and DeltaTableScan is done via the DataContext, but this
could/should be reviewed.
- For the moment, there is no distinction UNION vs UNION ALL in the
RecursiveUnion, it is always considered as UNION ALL
I'll provide ASAP a pull request so that everyone will be able to see the
current status of this feature.
was (Author: rubenql):
I'm working on an approach inspired by the [this
thread|http://mail-archives.apache.org/mod_mbox/calcite-dev/201712.mbox/%3CCAPSgeESFyih9_hf9=uMWFN00BCR7sjf0T+FRY2=ary3ygm1...@mail.gmail.com%3E]
and the implementation of 'WITH RECURSIVE' in PostgreSQL ([more
info|https://www.postgresql.org/docs/11/queries-with.html]). The key points are:
- New operators RecursiveUnion and DeltaTableScan:
-- Logical ones: LogicalRecursiveUnion, LogicalDeltaTableScan
-- Naive implementation in enumerable convention: EnumerableRecursiveUnion,
EnumerableDeltaTableScan
-- Corresponding rules to transform logical into enumerable
EnumerableRecursiveUnionRule, EnumerableDeltaTableScanRule
- The RecursiveUnion will represent a union of a recursive query, and will have
2 inputs: a non-recursive term (aka seed) + a recursive term. Its evaluation
will be as follows:
-- Initially, the seed will be processed, and its results will be placed in a
temporary location, as they will be used as initial input for the recursive
part (see DeltaTableScan description below)
-- Then, the recursive term will be processed, and its results will be placed
in the temporary location, as they will be used as the input for the next
iteration. This process will continue until the recursive term is finished.
- The DeltaTableScan will represent an auxiliary scan, not from a real table,
but the data generated by the recursive union: initially it will read the
result of the seed and then it will read the result of the previous iteration
of the recursive term, until no new result is generated.
TODOs:
- As a first implementation, the consumer-producer communication between
RecursiveUnion and DeltaTableScan is done via the DataContext, but this
could/should be reviewed.
- For the moment, there is no distinction UNION vs UNION ALL in the
RecursiveUnion, it is always considered as UNION ALL
I'll provide ASAP a pull request so that everyone will be able to see the
current status of this feature.
> Add algebraic operators to allow expressing recursive queries
> -------------------------------------------------------------
>
> Key: CALCITE-2812
> URL: https://issues.apache.org/jira/browse/CALCITE-2812
> Project: Calcite
> Issue Type: Improvement
> Components: core
> Affects Versions: 1.18.0
> Reporter: Stamatis Zampetakis
> Assignee: Julian Hyde
> Priority: Major
> Fix For: next
>
>
> In order to parse, optimize, and execute, recursive queries, expressed in
> SQL, datalog, SPARQL, or other high level language we need first to be able
> to represent recursive queries in relational algebra.
> The subject has been previously discussed in the dev list (see thread with
> title [Recursive query, graph query,
> Datalog|http://mail-archives.apache.org/mod_mbox/calcite-dev/201712.mbox/%3CCAPSgeESFyih9_hf9=uMWFN00BCR7sjf0T+FRY2=ary3ygm1...@mail.gmail.com%3E])
> where various ideas and optimizations were proposed.
> In this issue, we attempt to address only the algebraic part providing the
> following:
> # logical operator(s) for expressing recursion;
> # naive physical operator(s) for the Enumerable convention;
> # ability to create a recusive plan using the RelBuilder.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
