> > Nothing is free, including CFTRANSACTION. When you > > designate a set of queries as a transaction, the > > database has to take special actions which typically > > limit what other transactions can do while your > > transaction is running. (Note that any single query > > is a transaction - it'll either succeed or fail in > > its entirety.) So, if you unnecessarily chain a bunch > > of queries together within a single transaction, that > > may cause a significant bottleneck. > > Unless your database uses MVCC. When using MVCC the concept > of a transaction is slightly different, it is not just to > group queries, it is also to timestamp them and (in)validate > the tuples that are affected by them. Everything is in a > transaction, it simply is not possible to have a query that > is not in a transaction.
First, that's just in PostgresSQL, right? Second, to do that, it's essentially copying disconnected recordsets into memory, right? That seems like it might introduce its own problems, although I'd have to think it through a bit. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 ______________________________________________________________________ Get the mailserver that powers this list at http://www.coolfusion.com FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/[email protected]/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
