On 29 syys, 23:25, Anssi Kääriäinen <[email protected]> wrote:
> 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...
So, while investigating this I found out the reason for the
performance regression is calling _decimal_or_int for each row. As far
as I can tell there is no alternative to doing a call for each row.
The next idea was to cache the type of the column so that conversions
would be faster. This leads to an interesting test case:
cur.execute("select case when dbms_random.random > 0.5 then 0.1
else 0 end from testtable")
Guess what is the type of the column? It is both Decimal and int,
alternating based on the random result.
This seems like surprising behaviour to me. The problem is in
cx_Oracle, not Django code. In raw cx_Oracle queries you get ints and
floats mixed. I don't believe it is OK to return different types for
the same column in one resultset. I will report to cx_Oracle mailing
list and see if they have anything to say about this. DBAPI2 doesn't
offer any clear answer to this, all numeric types are put under same
type, NUMBER, no matter if they are ints, floats or Decimals.
To me it seems we can't do anything to this in Django. We simply don't
have enough information available in the outputtypehandler to guess
the type correctly.
- Anssi
--
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.
