[CALCITE-604] Invoke metadata providers via a class generated at runtime, rather than reflection

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Fix Version/s: 1.7.0
• Assignee: Julian Hyde
• Reporter: Julian Hyde
• Created: 24/Feb/15 20:14
• Updated: 24/Mar/16 19:11
• Resolved: 24/Feb/16 21:41

Description

Currently we dispatch to metadata providers using reflection. With this change, we generate a dispatcher class and compile using Janino.

Currently calls to metadata providers are dispatched via reflection (Method.invoke, see ReflectiveRelMetadataProvider, ChainedRelMetadataProvider and CachingInvocationHandler), and I suspect that planning a complex query (especially with tracing enabled) makes millions of calls. Reflection has a performance problem; lots of boxing and unboxing and creating temporary arrays and bound objects.

One option we considered to improve performance was moving to MethodHandle. (JDK 1.7 introduced http://docs.oracle.com/javase/7/docs/api/java/lang/invoke/MethodHandle.html, a more efficient way to invoke methods. Access control etc. is done when the handle is created, not each invocation.) However, MethodHandle.invoke can dispatch only within one provider.

So, we should generate a dispatcher class, and compile and instantiate at run time using Janino.

For each metadata interface we will need to add a handler interface that has the same methods but two extra arguments (a sub-class of RelNode, and a RelMetadataQuery). Previously these arguments were passed by calling "bind" on an UnboundMetadata.

We can also make the dispatcher cache the results within a metadata call. This should yield a performance improvement when, say, a join requires many kinds of metadata (rowCount, averageRowSize, selectivity) and they all rely on the rowCount of the input, and that rowCount is expensive to compute.

Issue Links

• is depended upon by: CALCITE-1147 Allow multiple providers for the same kind of metadata
• is related to: CALCITE-794 Detect cycles when computing statistics
• relates to: CALCITE-1048 Make metadata more robust
• relates to: CALCITE-1169 Memory leak caused by CALCITE-604 and CALCITE-1147