[
https://issues.apache.org/jira/browse/CALCITE-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14306825#comment-14306825
]
Vladimir Sitnikov edited comment on CALCITE-584 at 2/5/15 8:31 AM:
-------------------------------------------------------------------
{quote}Re (1) Table has a getStatistic() method that provides some
costing.{quote}
Does it account for "pushed down projections and filters"? No.
There is *no* cost based support for it.
Still have objections?
{quote}Re (2) and (3) for a lot of uses developers are happy to let go of the
"no object allocation" principle{quote}
(3) is regarding _type safety_. It is not about allocations, but a type safety.
Do you think lots of developers are willing sacrifice type safety for "eaiser"
{{new Object[]\{emp.id, emp.name, emp.deptno\}}}?
Should we rewrite Calcite in javascript then?
{quote} 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.{quote}
When you force "Object[] everywhere" approach, you end up with "allocate
multiple objects per *plan line*" that is _lots_ of allocations per resulting
row. This won't fly.
{quote} JDBC's ResultSet But it is difficult to implement, especially if there
are nulls.{quote}
JDBC is dead easy to implement when your downstream system is JDBC.
JDBC over ByteBuffer is harder indeed.
{quote} Where do you stop?{quote}
I do not want to stop at level 0. I do not want to be locked in "Object[]
everywhere".
{quote}If SplunkTable were a ScannableTable, it would have been easier to
implement and the rows would have been returned as Object[]s{quote}
How ScannableTable would simplify implementation of SplunkTable?
Can you pin-point?
was (Author: vladimirsitnikov):
{quote}Re (1) Table has a getStatistic() method that provides some
costing.{quote}
Does it account for "pushed down projections and filters"? No.
There is *no* cost based support for it.
Still have objections?
{quote}Re (2) and (3) for a lot of uses developers are happy to let go of the
"no object allocation" principle{quote}
(3) is regarding _type safety_. It is not about allocations, but a type safety.
Do you think lots of developers are willing sacrifice type safety for "eaiser"
{{new Object[]\{emp.id, emp.name, emp.deptno\}}}?
Should we rewrite Calcite in javascript then?
{quote} 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.{quote}
When you force "Object[] everywhere" approach, you end up with "allocate
multiple objects per *plan line*" that is _lots_ of allocations per resulting
row. This won't fly.
{quote} JDBC's ResultSet But it is difficult to implement, especially if there
are nulls.{quote}
JDBC is dead easy to implement when your downstream system is JDBC.
JDBC over ByteBuffer is harder indeed.
{quote} Where do you stop?{quote}
I do not to stop at level 0. I do not want to be locked in "Object[]
everywhere".
{quote}If SplunkTable were a ScannableTable, it would have been easier to
implement and the rows would have been returned as Object[]s{quote}
How ScannableTable would simplify implementation of SplunkTable?
Can you pin-point?
> 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)
