> > > 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 sqlalchemy@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.