>
> > 1. Query compilation... This
> > resulted in ~2x improvement.
>
> that seems very strange - 2x improvement in....the overall speed of your
> application? I've done an enormous amount of profiling - SQL compilation is
> miniscule compared to the SQL statement's execution itself and the fetching
> of rows.
>
This is because our workload mostly consists of a ton of Query.get() calls,
where the actual SQL execution/row fetching is very fast. That's probably
why we're even noticing all this overhead that would normally be
insignificant :-)
> To work around the "instance arguments being baked in", create the query
> like this:
>
> query.filter(SomeClass.somerecord ==bindparam("somerecord"))
>
> The params are then added using query.params(somerecord=x).
>
That's good to know! But as I understand it, compiled_cache still won't
really work, since a different statement instance is created each time,
right?
> Also if you can upgrade to 0.7, the result processors are now cached
> globally per type/dialect.
>
Sweet!
> If your use case is really about querying individual rows for display, not
> dealing with relationships, related objects or collections, you will of
> course get vastly better performance using the C extensions with plain
> select() constructs, receiving ResultProxy objects. Like the named tuple
> returned by query(X, Y, Z), the rows present in ResultProxy are also named
> tuples. A view that does something simple like "row.x, row.y, row.z"
> should be able to receive results from query(MyObject), query(MyObject.x,
> MyObject.y, MyObject.z), and Session.execute(select([mytable.c.x,
> mytable.c.y, mytable.c.z])) equally.
>
That's a great idea. Thanks!
Chung
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" 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/sqlalchemy?hl=en.
