[
https://issues.apache.org/jira/browse/CALCITE-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14306228#comment-14306228
]
Julian Hyde commented on CALCITE-584:
-------------------------------------
Yes, we do need to design a "better than Queryable" interface. Can you start an
email thread?
Re (1) Table has a getStatistic() method that provides some costing.
Re (2) and (3) for a lot of uses developers are happy to let go of the "no
object allocation" principle, because it makes for a simpler API.
I experimented for a while with an interface that looked a lot like JDBC's
ResultSet, and can be implemented with zero allocations (i.e. it doesn't return
an object for each row, and it has methods such as getInt(int column) for each
primitive type). But it is difficult to implement, especially if there are
nulls.
The Queryable API has its limitations because it allocates at least one object
per row (namely, the row). A truly efficient API would look like ResultSet or
even go beyond, allowing you to write column slices to ByteBuffers. Where do
you stop? If you are querying a typical data source its API will allocate
multiple objects per row, so there's little point trying to do better.
SplunkTable is a case in point. It generates code that calls SplunkQuery, which
returns an Object[] per row. The generated code is called by the consumer,
which might be, say, code generated by an EnumerableFilter. If SplunkTable were
a ScannableTable, it would have been easier to implement and the rows would
have been returned as Object[]s (just the same), and would be consumed by
generated enumerable code (just the same).
> Allow TableMacro to return Table other than TranslatableTable
> -------------------------------------------------------------
>
> Key: CALCITE-584
> URL: https://issues.apache.org/jira/browse/CALCITE-584
> Project: Calcite
> Issue Type: Bug
> Reporter: Julian Hyde
> Assignee: Julian Hyde
>
> The TableMacro.apply method used to return Table but in
> https://github.com/apache/incubator-calcite/commit/aa1f0983c126c23466deb990c96d6ff2dffd908c
> this changed to TranslatableTable. It seems reasonable to allow TableMacro
> to return other sub-types of Table, for example ScannableTable.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
