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

Julian Hyde commented on CALCITE-4539:
--------------------------------------

Can we try to separate functionality (pluggability) from performance (caching)?

Metadata types (e.g. {{RelMdCollation}}) are already pluggable, and you can add 
your providers (instances of {{RelMetadataProvider}}) at runtime. (I would not 
be surprised if user-defined metadata types are not as well supported in 
{{RelMetadataQuery}}; provide examples, if you have them.)

Some people have expressed concerns about the performance of Janino-generated 
handlers, but not about the functionality.

What problem would user-defined metadata handlers solve? One concern is that 
that they would not allow people to add new providers at runtime; another is 
that they would not follow the lifecycle of metadata caching (e.g. flushing 
metadata when there are major changes to the RelNode graph).

> Support pluggable metadata handlers and caching
> -----------------------------------------------
>
>                 Key: CALCITE-4539
>                 URL: https://issues.apache.org/jira/browse/CALCITE-4539
>             Project: Calcite
>          Issue Type: Improvement
>          Components: core
>            Reporter: James Starr
>            Priority: Major
>              Labels: pull-request-available
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> Calcite janino backed metadata does not support all the functionality that 
> the java reflection backed metadata system, such as customizing the cache to 
> use soft refs or have a max size.  Furthermore, the janino backed metadata 
> provider has many opinion that other are not universally shared, such as lazy 
> loading, requiring all rels to registered to a global singleton, use of 
> thread locals.  There is no easy way to currently override these opinions.
> Calcites metadata system should consist of 3 APIs: metadata consumer, 
> metadata implementors, metadata behavior.  The metadata consumer need to able 
> to fetch the appropriate metadata and invalidate the cache.  Currently this 
> is all done through RelMetadataQuery with some very leaky abstractions.  
> Metadata implementors create functions that extract the metadata for 
> particular node types.  These functions are registered via 
> ReflectiveRelMetadataProvider and ChainedRelMetadataProvider.  Attempting to 
> configure the internal behavior does not currently have an api.  Currently 
> porptions of it a scattered through out various class and are frequently not 
> extensible.  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to