> > If you want to use db.executesql() but remain portable, you can still have >> the DAL generate the SQL for you by using the ._select() method: >> >> db.executesql(db(query)._select(...)) >> >> Obviously in that case you don't get to hand optimize the SQL, but you >> still get the speed advantage of not converting the results to a Rows >> object (which is only significant for large results sets). >> > > While true, since he is going for performance in a high-traffic > environment that requires low-latency, such as a site that serves ads, he > would definitely want to hand-craft the SQL for complex and large queries > that slow things down. I wouldn't recommend doing it for every query, just > the slow ones. >
Sure. There are two reasons to use db.executesql: (1) save time by not having the DAL convert large results sets to a Rows object, (2) hand write SQL that the DAL either can't generate or generates less efficiently. I was just referring to case #1. Anthony
