Mailing-List: contact dev-help@calcite.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@calcite.incubator.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CAKi3F37bMK919qF3PduoseXAWzGpwFYgyGEcz6d2LAJKcrcZyQ@mail.gmail.com>
References: 
 <CAKi3F37AAYnV+DDwJfq_3P4QRR42XM+F9uLM04Jkvcqj66BJkw@mail.gmail.com>
	<19C65F50-0CAA-4D95-9087-AA43B8BF9BC0@apache.org>
	<CAB=Je-GuO_x_E=8MT4bA10v1mUcYsjju0kZt5pOPrzrDK+LohQ@mail.gmail.com>
	<0DFFBBF0-607C-44A1-9F7B-3B7596DDB86F@gmail.com>
	<CAKi3F37bMK919qF3PduoseXAWzGpwFYgyGEcz6d2LAJKcrcZyQ@mail.gmail.com>
Date: Fri, 24 Jul 2015 23:56:43 +0300
Message-ID: 
 <CAB=Je-G_vpy+QfXLUGhyHtPxHMbFHX5FY1nyFtBXNi9T16bBGw@mail.gmail.com>
Subject: Re: Unclear hard-coding in planner and other parts of source code
From: Vladimir Sitnikov <sitnikov.vladimir@gmail.com>
To: "dev@calcite.incubator.apache.org" <dev@calcite.incubator.apache.org>
Content-Type: text/plain; charset=UTF-8

Costing model indeed begs improvements.
However, to improve it some real-life cases are required.

It happens so that even current formulas work (Julian-only-knows-how)
for current unittest/etc cases.

This is not completely new topic, no-one just came up with test cases and fixes.

>To set cost I overrode computeSelfCost method where cpu cost and io cost
was multiplied by length of row. But it didn't help.

Your next battle would probably be "costing of computation pushdown".
In other words, costing of computations in java vs costing of the same
operations performed in your storage.
I've noticed that Calcite prefers "to just full scan the data sources"
and join/aggregate in java, however your mileage may vary.

Vladimir