francesco-gini88 commented on a change in pull request #2620:
URL: https://github.com/apache/calcite/pull/2620#discussion_r771716821
##########
File path: core/src/test/java/org/apache/calcite/test/JdbcAdapterTest.java
##########
@@ -50,23 +50,25 @@
* same time. */
private static final ReentrantLock LOCK = new ReentrantLock();
- /** VALUES is not pushed down, currently. */
+ /** VALUES is pushed down. */
@Test void testValuesPlan() {
final String sql = "select * from \"days\", (values 1, 2) as t(c)";
- final String explain = "PLAN="
- + "EnumerableNestedLoopJoin(condition=[true], joinType=[inner])\n"
- + " JdbcToEnumerableConverter\n"
+ final String explain = "PLAN=JdbcToEnumerableConverter\n"
+ + " JdbcJoin(condition=[true], joinType=[inner])\n"
+ " JdbcTableScan(table=[[foodmart, days]])\n"
- + " EnumerableValues(tuples=[[{ 1 }, { 2 }]])";
+ + " JdbcValues(tuples=[[{ 1 }, { 2 }]])";
Review comment:
FWIW I think the test and comment `VALUES is not pushed down,
currently.` was giving the false impression that `Values` can't be pushed down
into the db. A query like `select * from "days", (values 1, 2) as t(c) where
t.c = "days"."day"` would have had a plan with VALUES pushed down
```
"PLAN=JdbcToEnumerableConverter\n"
+ " JdbcJoin(condition=[=($2, $0)], joinType=[inner])\n"
+ " JdbcTableScan(table=[[foodmart, days]])\n"
+ " JdbcValues(tuples=[[{ 1 }, { 2 }]])"
```
The reason why `VALUES` was not pushed down is because the cross join
couldn't be pushed down in the first place.
On the point that the plan is less efficient and that it would be more
efficient to "duplicate in-memory" rows. I can see where your observation is
coming from. However, this test case is quite simple. In reality I would expect
other aspects to matter as well. For instance in the in memory implementation
of the cross join I _think_ that the inner iterator is instanciated multiple
times. If the inner iterator happens to be `JdbcToEnumerableConverter` that
would equate to running a query multiple times, because the inner iterator is
created multiple times. This would mean fetching rows multiple times plus
adding latency multiple times.
In any case, I don't think this is the pr to address VALUES optimisations
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
