> I decided to try it and have a look into generated code for the expression > like
Nice. In fact, the difference of the approaches is as follows: 1) ProjectableFilterableTable requires _interpreter_ to execute the expression since it the set of "non-processed by backend" filters might alter in the runtime. 2) Your own sub-class of TableAccessRelBase might seem to be "much more coding", however, I believe the most "complex" part is the code that will actually analyze filter conditions. The "analysis" logic would be pretty much the same for both approaches. If you find yourself at "too much Calcite coding" state (especially linq4j stuff), then you might be doing it wrong. I would say current implementation of Interpreter is not yet stable, so some issues are to be identified, and some issues are to be fixed (for instance, current Interpreter always stores the full resultset in a ArrayList). Having said that, at current point I am more inclined to a RestScan(optinional_filters) approach (i.e. your own sub-class of a TableAccessRelBase that knows additional pushdown filters). Vladimir
