On Apr 9, 2010, at 4:51 PM, nekto0n wrote:
> Hi there!
> I'm now in the process of migrating from pure kinterbasdb to
> SQLAlchemy. Everything is fine except for speed of insertions and
> maybe updates. After some time of profiling I found out that a
> significant amount of time is spent on getting "rowcount" after
> execution. It takes about 5 seconds vs 41 spent on 3000 insertions
> themselves. That is 12%. Not much, but still.
> Digging further showed that rowcount attribute of kinterbasdb.Cursor
> is a getter, which remotely calles to Firebird Database. Here is the
> comment from _kicore_cursor.c source file: "Determining rowcount is a
> fairly expensive operation that requires an isc_dsql_sql_info call".
> I wonder if there's any possible way to make getting "rowcount"
> optional or lazy?
done some more digging here. The unfortunate thing is that our result object
autocloses after any non-result returning operation, and as such it
unconditionally retrieves the rowcount, typically a cheap/free operation, so
that it is availble for those DBAPIs like kinterbasdb who require the cursor to
be available.
This means we can't make "rowcount" lazy. I can add an option to the
kinterbasdb dialect to just turn off rowcount entirely, though. There seems
to be ongoing debate about whether or not "rowcount" works at all with
kinterbasdb. It seems to work perfectly over here, so it will just be up to
the flag.
Here's the CHANGES for that change:
- The functionality of result.rowcount is now disabled
by default, and can be re-enabled using the 'enable_rowcount'
flag with create_engine(), as well as the 'enable_rowcount'
execution context flag on a per-execute basis. This because
cursor.rowcount requires cursor access (can't be evaluated
lazily since the result auto-closes) and also incurs an
expensive round-trip.
so if you wanted to use the "versioning" feature with the ORM, you'd use an
engine that has the flag turned on with that application. otherwise the ORM
knows not to use rowcount.
>
> Thanks!
>
> --
> You received this message because you are subscribed to the Google Groups
> "sqlalchemy" group.
> To post to this group, send email to sqlalch...@googlegroups.com.
> To unsubscribe from this group, send email to
> sqlalchemy+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sqlalchemy?hl=en.
>
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalch...@googlegroups.com.
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
