Hi Stefan, yep, makes sense. I think monetdb is a clean architecture
designed for performance. Thanks for your responses. Dru
On Mon, Nov 11, 2013 at 12:06 AM, Stefan Manegold
Hi Dru,
it's good to know that your solution works for you ;-)
My point was just for the records to explain the intentions and specifics of our decimal implementation. In fact, in this line, we never had the need to know the scale information in MAL; at the end, the position of the decimal point is only relevant to the human user; the MonetDB kernel and the CPU do not (need to) know about any related semantics.
Best, Stefan
Hi Stefan,
Thanks.
I don't use the int type anymore. MAL recognizes the CAST and coverts the OVER clauses to dbl.
Also, at the MAL implementation level, in C, this scale info was not
I think that is fine. I recognize that SQL was added to the engine and
BAT structures are essentially a different system.
Best,
Dru
On Sun, Nov 10, 2013 at 11:12 PM, Stefan Manegold < Stefan.Manegold@cwi.nl > wrote:
Hi Dru,
please be aware that decimal are essential integers --- just the decimal point is shifted; however, it's shifted identically for all values in a BAT; i.e., if your decimal(9,4) column holds, say, values between 1.1 and 6789.1234, the underlying BAT holds integer values between 11000 and 67891234; thus, both ordinality and relative ratios are
----- Original Message ----- present. that maintained.
Best, Stefan
----- Original Message -----
Hi,
While thinking about this in the morning yesterday, I came up with a solution. First let me explain a bit more about the challenge.
I was implementing percentile_cont for a contract project. I added the syntax to the parser. On the backend I was using dense_rank as my initial template. Because dense_rank takes ANY_1, it would receive either a flt or int
thought i had everything working great until i worked with a decimal column. Because the decimal type is just an int type scaled, and the BAT doesn't record this, I was stuck. The window function generates a result based on the values (vs dense_rank just needing to know ordinality)
My solution was to modify the AST after the parse to inject a CAST to a dbl on the OVER portion. It was not my ideal solution, since it will force an intermediate to be created for any type that isn't a double. None the less, the MAL optimizers work correctly and the function handles all types.
Best,
Dru
On Sat, Nov 9, 2013 at 8:22 AM, Lefteris < lsidir@gmail.com > wrote:
I second that! Are you sure that you cannot come up with an alternative algorithm for your aggregation that does not need this information (and possibly be faster) ?
On Sat, Nov 9, 2013 at 11:26 AM, Stefan Manegold < Stefan.Manegold@cwi.nl > wrote:
Hi Dru,
the decimal scale information is only maintained in the SQL catalog and given that decimals are stored as integers in MonetDB, neither the MonetDB kernel, nor MAL usually need to know about decimals or their scale.
Hence, the question is, whether/why your aggregate functions would need to know about decimals or their scale?
Best, Stefan
Dru Nelson < drudru@gmail.com > wrote:
HI,
I"m working on writing an aggregate in in C that is a MAL function.
I've
run into a problem with decimal types.
I've noticed that when I inspect the BAT inputs for various types,
are coerced to simpler types. (flt,dbl -> dbl). (int, decimal -> int). There is also no other information in the BAT structure to see the type.
I notice that a SQL select gets the type info passed in as
BAT. I they parameters
for the 'exportValue' output.
For example:
sql.exportValue(1,".","second_single_value","decimal",9,3,8,_4,"");
How can I get this type information ('decimal', etc.) passed into my function?
Dru
________________________________
developers-list mailing list developers-list@monetdb.org https://www.monetdb.org/mailman/listinfo/developers-list
-- | Stefan.Manegold@CWI.nl | Database Architectures (DA) | | www.CWI.nl/~manegold | Science Park 123 (L321) | | +31 (0)20 592-4212 | 1098 XG Amsterdam (NL) |
_______________________________________________ developers-list mailing list developers-list@monetdb.org https://www.monetdb.org/mailman/listinfo/developers-list
_______________________________________________ developers-list mailing list developers-list@monetdb.org https://www.monetdb.org/mailman/listinfo/developers-list
_______________________________________________ developers-list mailing list developers-list@monetdb.org https://www.monetdb.org/mailman/listinfo/developers-list
-- | Stefan.Manegold@CWI.nl | DB Architectures (DA) | | www.CWI.nl/~manegold/ | Science Park 123 (L321) | | +31 (0)20 592-4212 | 1098 XG Amsterdam (NL) |
_______________________________________________ developers-list mailing list developers-list@monetdb.org https://www.monetdb.org/mailman/listinfo/developers-list
_______________________________________________ developers-list mailing list developers-list@monetdb.org https://www.monetdb.org/mailman/listinfo/developers-list
-- | Stefan.Manegold@CWI.nl | DB Architectures (DA) | | www.CWI.nl/~manegold/ | Science Park 123 (L321) | | +31 (0)20 592-4212 | 1098 XG Amsterdam (NL) |
_______________________________________________ developers-list mailing list developers-list@monetdb.org https://www.monetdb.org/mailman/listinfo/developers-list