On Wednesday 03 February 2010, you wrote: > Blueprint changed by Xavier (Open ERP): > 2. Though it's not quite ideal (understatement of the day), the > `NUMERIC` postgres type...
Are we sure all this will not introduce a performance issue on the server? AFAIK, postgres suggests that NUMERIC is slower than float. Yes, float is bound to have rounding errors (actually noticable if we bring it to less than 2 decimal places from the precision we want) [1], but it's much faster. Could we write a dummy python (standalone) program and test performance with SQL's numeric, float, and python's Decimal etc? We always have to consider the exponential[2] nature of un-optimizations: perhaps a number calculation is only a few μsecs, but when we use SUMs of those fields, and then also repeat [3] those sums a few hundred times, the cost of a calculation will be much wasted time. [1] I mean, if we want NUMERIC(12,4), and float can have 6 decimal places for the range we use, then float maps ok. If float drops down to 4, we could introduce a +-1 digit difference (actually mathematically correct for non- trivial calculations). If, again, we only use NUMERIC(12,2) for 2-decimal money (like Eur), numeric already calcs wrong (eg. for VAT). [2] The time needed for an operation is the product of all these factors like SQL queries, ORM code, Python representation layers, high-level code (like report loops) etc. Each time we put another abstraction layer, we add one factor. [3] There is many unfortunate python loops in the code, which keep querying the SQL for results, separately per orm row. _______________________________________________ Mailing list: https://launchpad.net/~openerp-expert-framework Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-expert-framework More help : https://help.launchpad.net/ListHelp
