Hi all,
I have a table with an INT column.
The table is sorted by that column, and monetdb has recognized the sort order.
While performing this query:
--------------
SELECT * FROM table WHERE column = 12345678900;
--------------
monetdb converts <table.column> to BIGINT/LNG as evidenced by the trace:
--------------
3612684 | X_17=<tmp_2352>[89617785] := batcalc.lng(X_16=<tmp_7142>[89617785]);
--------------
This seems logical behavior since the condition value would overflow INT. (Of course the result set is empty by definition, but it’s a valid query)
However, the same happens when I then perform subsequent queries with values that *can* be represented by INT:
--------------
SELECT * FROM table WHERE column = 123;
--------------
It is only when an explicit INT value is entered, that the type conversion is stopped for that query and subsequent ones:
--------------
SELECT * FROM table WHERE column = CAST(123 AS INT);
--------------
In other words, once the type conversion is performed once, it seems to “stick” to subsequent queries.
Type conversion on that column takes ~4s on a 90MM row table here, while the regular query time is usually sub-millisecond.
Entering the “wrong" value once will influence the DB performance heavily until restarted, which is far from a desirable scenario.
Of course I could always clamp my value to INT range at the application level, but this is brittle, and the DB could do the right thing here.
Is there a design consideration that I’m missing, or should I file this as a bug/performance issue?
Thanks,
Dennis
