[jira] [Commented] (PHOENIX-2523) Use same client/server caching mechanism for Phoenix/Calcite

["Maryann Xue (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/PHOENIX-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15056038#comment-15056038 ] 

Maryann Xue commented on PHOENIX-2523:
--------------------------------------

Before CALCITE-911, the Calcite schema always assumed that its underlying implementation is "cached", which means it caches all the sub-schema names as well as table names but only retrieves the table object when needed. I assume, though, we can now implement the schema in a non-caching way, with the help of CALCITE-911, so the problem comes down to how non-caching schema copes with materialization declaration (i.e. our secondary index declaration).
Currently, in Calcite, we should define a list of existing materializations at the creation of the VolcanoPlanner, which at its own optimization stage, decides which materializations will be applicable and will be used according to the query. This means we have to pre-load all the index tables anyway whether we implement a caching schema or non-caching schema. I would imagine having an interface like returning a list of applicable materializations based on a specific table could make this work. But I guess the interface has to go well with the general materialization model in Calcite as well, in which a materialization is defined as a relational expression and can be anything from a TableScan to an Aggregate or a Join, etc.
[~julianhyde], can you share some thoughts on this issue? Not sure how the interface should be exactly, and we haven't created a JIRA in Calcite yet.

> Use same client/server caching mechanism for Phoenix/Calcite
> ------------------------------------------------------------
>
>                 Key: PHOENIX-2523
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-2523
>             Project: Phoenix
>          Issue Type: Bug
>            Reporter: James Taylor
>            Assignee: Maryann Xue
>
> Rather than query through the DatabaseMetaData APIs, Phoenix/Calcite should use the same client/server caching mechanism as standalone Phoenix. One challenge is that Calcite looks at the schema first and then at the tables under that schema (one level at a time), while Phoenix doesn't have a physical representation of a schema. Instead, it resolves a table given the schema name and table name together. One solution may be to never give an error in Phoenix/Calcite when a schema level is traversed, but only actually resolve when the next level is traversed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)