Thomas Lockhart wrote:
>
> ...
> > > Speed? :) (smirk)
> > If you want MySQL, you know where to find it. ;)
>
> Hmm. Assuming that "speed" is the outcome of dropping transaction
> support is a bit simplistic (and linking "speed" and "mysql" and "no
> transactions" has been shown to be a hollow argument). In fact, without
> transactions (or with a transaction for every query) you see the full
> effects of requiring a "commit" at every query. Buffers must be written
> and everything having to do with the query must be cleaned up. With
> transactions, some of those steps are postponed until commit, and you
> will see a per-query performance gain by lumping many queries into one
> transaction.
>
> Also, without transactions and without MVCC, you must tightly coordinate
> every query and every affected row in every table, which can choke off
> performance as you scale to larger numbers of clients.
In fact, some could argue that the default behavior of PostgreSQL
should be changed (or at least have an option) to behave like
Oracle, where a transaction is implicitly begun at the first
encounter of an INSERT/UPDATE/DELETE - or in PostgreSQL's case, the
first submitted statement. That would make PostgreSQL behave much
better out-of-the-box in comparison to mySQL, and would satiate the
desires of those Oracle folks transitioning to PostgreSQL that do a:
DELETE FROM foo;
-- Nuts!
ROLLBACK;
and expect their DELETE to be undone.
FWIW,
Mike Mascari
mascarm@mascari.com
