(reply- s/hackers/general/)
Well I put that sort of thing into my application logs, personal preference
for now.
It seems to me mixed transaction tables are likely to create an error prone
environment for little real gain.
No transactions doesn't necessarily mean faster (or slower). IMO MySQL has
that feature for backwards compatibility. Little to do with performance.
It would be good for claims regarding overheads/performance issues to be
backed by reproducible experiments, or at least interesting
statements/arguments.
I've used MySQL and it was far better than Postgresql when Postgresql was
Postgres95 (yuckyuckyuck!). While Postgresql has really gone a long way,
MySQL seems to have been stuck in denial till recently.
Will be interesting to see if MySQL can pull off the Windows vs Mac trick :).
I hope it will be a good clean fight :).
Cheerio,
Link.
At 11:05 PM 28-10-2001 -0400, Mike Rogers wrote:
>What that does is very simple: it rolls back the one that is keeping track
>of it's transactions. Think of the overhead if someone doesn't have
>transactional statements. The idea is, in PGSQL, all inserts and updates
>are essentially logged so that they can be rolled back. Here is the MySQL
>concept:
> Have a log table that logs all transactions (lets say, failed or not)
> 1. begin transaction
> 2. insert into non-transactional table 'user did this, status-
>unprocessed'
> 3. insert into payment table
> 4. insert into product table
> 5. update to processed
> 6. insert into shipping
> 7. update to 'pending shipping'
> Perfectly common transaction that happens. Now! What if you want the
>entry inserted and dealt with as a status and what happens, but you don't
>want all the evidence of that to disappear when you hit rollback. It means
>you can have some things roll back and others don't. In PGSQL, that would
>have to be begin/rollback for only transactional entries.
