[
https://issues.apache.org/jira/browse/CALCITE-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14308006#comment-14308006
]
Vladimir Sitnikov commented on CALCITE-584:
-------------------------------------------
{quote}Handling rejected filters – at run time – is a really important
requirement, and it is something that EnumerableTableScan simply cannot
do.{quote}
On contrary, it can do that like a charm.
Here's my card:
1) Compile all kinds of fillters when compiling EnumerableTableScan. For
instance, each filter to separate method.
2) At runtime, call {{.scan}}, then analyze which filters did pass through and
just avoid extra filtering by the generated code (e.g. several plain old
boolean fields).
It allows you to compute proper result while it keeps code manageable and
performance in a good health.
Well, EnumerableTableScan can even ignore the verification of rejected filters.
It can always double-check "just in case". We can treat is as a missing
optimization and still comply with "support of rejected filters" requirement as
we do not declare Scannable to be a top performance dog yet.
> 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)
