calcite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Hyde <>
Subject Re: Sort push down rule on custom adapter
Date Fri, 26 Feb 2016 18:47:30 GMT
Turn on plan tracing and look at the final planner space. Hopefully you will see a plan with
MyAdapterSort and another with EnumerableSort. Is the cumulative cost of EnumerableSort lower?
If so, that would explain why Calcite is choosing it. You might need to tweak the cost function
of MyAdapterSort to make sure that it is lower cost.


> On Feb 26, 2016, at 10:41 AM, Miguel Oliveira <> wrote:
> Hi,
> I’m implementing an adapter for Apache Calcite and I want to push down as
> much processing as possible to the datasource side in order to minimize the
> operations that are performed in memory. Despite of having a node named
> MyAdapterSort and a rule to convert Sort to MyAdapterSort, my sorting
> operation is not included in the plan and is always performed in memory.
> What can be done to force the usage of my sort node implementation (instead
> of falling back to EnumerableSort).
> I‘m adding an example of my query (1) and the query (2) of a test with the
> Mongo adapter, which as the same behaviour (projection and sort).
> Query 1: "select LeadSource from MyAdapter.Opportunity order by LeadSource"
> PLAN=EnumerableSort(sort0=[$0], dir0=[ASC])
> MyAdapterToEnumerableConverter
> MyAdapterProject(LEADSOURCE=[$0])
>  MyAdapterTableScan(table=[[MyAdapter, OPPORTUNITY]])
> Query 2: "select * from zips order by state limit 2"
> PLAN=MongoToEnumerableConverter"
> MongoSort(sort0=[$4], dir0=[ASC])\n"
> MongoProject(CITY=[CAST(ITEM($0, 'city')):VARCHAR(20) CHARACTER SET
> \"ISO-8859-1\" COLLATE \"ISO-8859-1$en_US$primary\"],
> \"ISO-8859-1\" COLLATE \"ISO-8859-1$en_US$primary\"], ID=[CAST(ITEM($0,
> \"ISO-8859-1$en_US$primary\"])\n"
> MongoTableScan(table=[[mongo_raw, zips]])");
> Best regards,
> Bruno Miguel

View raw message