I noticed this two pieces of code:
1. in SqlToRelConverter:
if (preExprs.size() == 0) {
// Special case for COUNT(*), where we can end up with no inputs
// at all. The rest of the system doesn't like 0-tuples, so we
// select a dummy constant here.
final RexNode zero = rexBuilder.makeExactLiteral(BigDecimal.ZERO);
preExprs = ImmutableList.of(Pair.of(zero, null));
}
2. in RelBuilder:
// Some parts of the system can't handle rows with zero fields, so
// pretend that one field is used.
if (fieldsUsed.isEmpty()) {
r = ((Project) r).getInput();
}
They run in this order, and the 2nd overrides the former. The end result is
that for query `SELECT COUNT(*) FROM foo`, the result of sql-to-rel
conversion is:
LogicalAggregate(group=[{}], EXPR$0=[COUNT($0)])
LogicalTableScan(table=foo)
instead of:
LogicalAggregate(group=[{}], EXPR$0=[COUNT($0)])
LogicalProject(DUMMY=[0])
LogicalTableScan(table=foo)
In our implementation we push the projection to table scan. Without the
project, we fetch full rows, even though the aggregation uses no row.
The code was introduced in
https://issues.apache.org/jira/browse/CALCITE-3763, but maybe it was broken
later.
Do you think this is an issue?
Viliam
--
This message contains confidential information and is intended only for the
individuals named. If you are not the named addressee you should not
disseminate, distribute or copy this e-mail. Please notify the sender
immediately by e-mail if you have received this e-mail by mistake and
delete this e-mail from your system. E-mail transmission cannot be
guaranteed to be secure or error-free as information could be intercepted,
corrupted, lost, destroyed, arrive late or incomplete, or contain viruses.
The sender therefore does not accept liability for any errors or omissions
in the contents of this message, which arise as a result of e-mail
transmission. If verification is required, please request a hard-copy
version. -Hazelcast
