Richard Davies wrote: > On the first question, I'd suspect that many pages of many (simple) > web applications just have a one-to-one mapping between the web page > and a single line of SQL on a normalized database - e.g. a page > listing all events (single SELECT), a page listing all people at an > event (single SELECT), a form to add an event (single INSERT), etc. > Wrapping these in transactions is pure overhead.
When it comes to overhead... As far as I know PostgreSQL in autocommit mode will wrap each statement (even SELECT) in an implicit transaction. From http://it.toolbox.com/blogs/database-soup/postgresql-application-performance-tips-part-1-13172: > While you may think that you are not using transactions for singleton > read-only SELECT statement, in fact every single statement in > PostgreSQL is in a transaction. In the absence of an explicit > transaction, the statement itself is an implicit transaction. So what Django does now (and what DB API suggests) by starting and explicit transaction up to the first save(): BEGIN; SELECT ... UPDATE ... COMMIT; is actually more efficient then equivalent in auto-commit mode: implicit begin; SELECT ... implicit commit; implicit begin; UPDATE ... implicit commit; And the more statements you have the worse auto-commit is. So if this ticket should be fixed then only for consistency with other DBs, not for performance reasons. But I actually think that performance is more important here. It's not hard to do explicit rollback anyway in your view code if you're recovering from an exception. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" 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/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
