Would you be so kind to provide a "superball" ? MonetDB5-server in http://monetdb.cwi.nl/testing/projects/monetdb/Current/.DailyBuilds./ 0_latest/SourceTarBalls/ cannot be built on it's own..

In addition, on the Mac there is builtin readline (NetBSD: readline.h,v 1.11 2004/01/17) , and mclient does not use it. Headers: #include <readline/readline.h>, #include <readline/history.h> Libs: /usr/lib/libreadline.dylib

Darwinports installed as dependency readline 5.0 : Headers: /opt/local/include/readline : chardefs.h history.h keymaps.h readline.h rlconf.h rlstdc.h rltypedefs.h tilde.h Libs: /opt/local/lib/libreadline.5.0.dylib /opt/local/lib/ libreadline.a /opt/local/lib/libreadline.5.dylib /opt/local/ lib/libreadline.dylib

BR, Alex

On May 13, 2007, at 9:21 PM, Martin Kersten wrote:

Hello, thanks to your report I was able to construct a test case that uncovered an error in the decimal conversion. I am not sure if this solves your problem, but at least it avoids a series of errors.

The problem occurred if you did not provide 4 decimal digits.

Added test decimal.SF-1718253 to BugTracker directory

The updated version is in the head branch.

Alexandru Toth wrote:

...

Hello, Please advice on the rounding errors 73897488.0537 vs 74523898.6957. CREATE TABLE fact_cub ( figure decimal(10,4) DEFAULT NULL, dim_0 int DEFAULT NULL, dim_1 int DEFAULT NULL, dim_2 int DEFAULT NULL, dim_3 int DEFAULT NULL, dim_4 int DEFAULT NULL, dim_5 int DEFAULT NULL ) INSERT INTO fact_cub VALUES ('190.9420',4,49,39,17,3,2); INSERT INTO fact_cub VALUES ('998.9138',4,49,39,17,3,3); ...... As sanity check, the count(*) returns same number. sql>select count( figure ) from fact_cub where 4 <= dim_0 and dim_0 <= 15 and dim_4 = 2 and dim_5 = 2 and 57 <= dim_1 and dim_1 <= 64; % sys.fact_cub # table_name % count_no_nil_figure # name % int # type % 6 # length [ 149406 ] Timer 1611.294 msec sql>select 0, sum( figure ) from fact_cub where 4 <= dim_0 and dim_0 <= 15 and dim_4 = 2 and dim_5 = 2 and 57 <= dim_1 and dim_1 <= 64; % ., sys.fact_cub # table_name % single_value, sum_figure # name % smallint, decimal # type % 1, 12 # length [ 0, *73897488.0537 * ] Timer 1842.599 msec mysql> select count( figure ) from fact_cub where 4 <= dim_0 and dim_0 <= 15 and dim_4 = 2 and dim_5 = 2 and 57 <= dim_1 and dim_1 <= 64; +-----------------+ | count( figure ) | +-----------------+ | 149406 | +-----------------+ 1 row in set (13.59 sec) mysql> select 0, sum( figure ) from fact_cub where 4 <= dim_0 and dim_0 <= 15 and dim_4 = 2 and dim_5 = 2 and 57 <= dim_1 and dim_1 <= 64; +---+---------------+ | 0 | sum( figure ) | +---+---------------+ | 0 | *74523898.6957* | +---+---------------+ 1 row in set (7.45 sec) BR, Alexandru On May 13, 2007, at 4:26 PM, Martin Kersten wrote:

...

Alexandru Toth wrote:

...

Hello, Replacing 2 comparisons with between is not necessarily faster in databases other than Monet. Proof (same 7 million rows table):

We looked at the plans and noticed that indeed the optimizer missed a point. It has been checked in the current trend.

...

mysql> select 0, sum( figure ) from fact_cub where dim_0 between 4 and 15 and dim_4 = 2 and dim_5 = 2 and dim_1 between 57 and 64; +---+---------------+ | 0 | sum( figure ) | +---+---------------+ | 0 | 74523898.6957 | +---+---------------+ 1 row in set (13.14 sec) mysql> select 0, sum( figure ) from fact_cub where 4 <= dim_0 and dim_0 <= 15 and dim_4 = 2 and dim_5 = 2 and 57 <= dim_1 and dim_1 <= 64; +---+---------------+ | 0 | sum( figure ) | +---+---------------+ | 0 | 74523898.6957 | +---+---------------+ 1 row in set (7.51 sec) Replacing 2 comparisons with one logic AND might be faster, but SQL is not as readable Cheers, Alexandru