Hi, and thanks for your attention. I know you must be extremely busy with other issues of the feature freeze. I just want to make some things clear:
> Based on the above I am -1 on having a flag that interprets NUMBER > fields as floats. There is already an Oracle data type to use for > this. > The flag does not affect the interpretation of NUMBER columns with scale and precision. True, in its current form, it turns bare NUMBER columns (decimal- precision floating point) to floats. But these are columns that are not generated by Django's built-in fields; if you have them, you are doing something Oracle-specific. The flag is mostly intended to improve cross-database compatibility; other than that, it offers a very clear trade-off and it is off by default. It really shouldn't hit anybody by surprise. > > > I am not yet sure if it is a good idea or not. The > > > basic problem is granularity: wouldn't you want to do this per query, > > > or even per expression basis? > > > > No, I don't; the issue is cross-database compatibility. > > > The problem seems to be that on Oracle, 1.1 is NUMERIC, and that is > something which _is_ a decimal in Python. We should not change that. > > To me it seems the answer is to use to_binary_float/to_binary_double > in raw SQL queries. For example: > But this is an Oracle-specific solution. Exactly the thing I'm trying to avoid. > > I tested the pull request 393 (the speedup to ._rowfactory). Above > test case, and the decimal case runs in around one second, the float > case in 0.1 seconds. So, there is a regressions for decimals. On the > other hand floats are way faster. Will investigate... > I confirm your findings: Running with different parameters (10,000 rows) I found Decimals are ~1.8x slower, floats are ~3 times faster, and significantly, ints are ~2 times faster. I suspect in the typical Django application, most numbers are ints. I investigated a little myself, and found the reason to be the redundant lookup in _decimal_or_int(): It was referring to Decimal as "decimal.Decimal". I moved that to a default argument, and got performance to be ~40% better than trunk for decimals too. The pull request is already updated. > As for new features for 1.5: there is roughly a day before feature > freeze. Getting any new ticket into 1.5 is really unlikely at this > point, existing pull requests have priority. > FWIW, the pull request exists (402). Thanks for your help, Shai. Shai. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
