in reply to Re: How to Speed up MySQL w/ Perl
in thread How to Speed up MySQL w/ Perl

assuming you have transactions turned on (which you really, really want), and RaiseError as well)

I'm going to take issue with the transactions part of this statement. Transactions can be necessary in many cases. However, one of the benefits of MySQL over, say, Oracle is that you can choose whether or not you want transactions or not. In a majority of cases, you don't actually need transactions because your transactions are all one statement long.

The benefit of ACID-compliant transactions is the ability to rollback multi-statement changes. If your one-statement transaction fails, nothing has actually occurred to change the state of the tables involved.

By using a table type that doesn't have transactions (such as the default MyISAM), you can do many activities (like bulk inserts) 5-10x faster. If you don't need transactions, that's a huge benefit.

------
We are the carpenters and bricklayers of the Information Age.

Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

I shouldn't have to say this, but any code, unless otherwise stated, is untested

Replies are listed 'Best First'.
Re: How to Speed up MySQL w/ Perl
by Abigail-II (Bishop) on May 26, 2004 at 13:43 UTC
    If your one-statement transaction fails, nothing has actually occurred to change the state of the tables involved.
    It would only be a one-statement transaction if %Data contains less than two elements. It's unlikely that that is the common case.

    Transactions are a bit like "use strict" (except they prevent you from real harm). While there are cases you don't need "use strict", it's a good idea to get into the habit of using them, and only in special cases you don't use them.

    By using a table type that doesn't have transactions
    ... you have committed yourself to never be able to use transaction on modifications of that table. Why bother with a database in such a case? Might as well use a bunch of DBM files.
    If you don't need transactions
    Famous last words, and belongs in the series "we don't need backups", "we don't need redundancy", "we don't need to look around when crossing the street". And indeed, most of the time, you don't need them. You just never know when you do.

    Abigail

[reply]
      It would only be a one-statement transaction if %Data contains less than two elements. It's unlikely that that is the common case.

      Each element of %Data would be a different transaction anyways. Unless, of course, you plan on having a 2-million+ insert transaction. That will strain any rollback segment. (This is actually one reason why I'm moving from Oracle to MySQL.)

      you have committed yourself to never be able to use transaction on modifications of that table.

      Nope. ALTER TABLE FOO.BAR TYPE=INNODB now means that the table is ACID-transaction capable.

      And, I can think of a specific case where I know I don't need transactions - a database that is loaded once and will never be written to. In that case, I don't want the overhead of a transaction on my SELECT statements.

      ------
      We are the carpenters and bricklayers of the Information Age.

      Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

      I shouldn't have to say this, but any code, unless otherwise stated, is untested

[reply]
        Each element of %Data would be a different transaction anyways.
        "Would be"? What do you mean? The way I wrote it, it's in one transaction as it should be.
        Unless, of course, you plan on having a 2-million+ insert transaction. That will strain any rollback segment.
        *blink* I wouldn't think for a nanosecond to not put them in one transaction. 2 million chances for something to go wrong - better protect myself against it. And since no futher information is available, I'm not going to assume that a partially modified table is acceptable. Besides, it's not only failure you want to protect yourself against - other processes should see a consistent table, and not one where half the rows are modified, and the other half aren't.
        And, I can think of a specific case where I know I don't need transactions - a database that is loaded once and will never be written to. In that case, I don't want the overhead of a transaction on my SELECT statements.
        Quite a specific case, and not at all applicable to the OP's problem where the database is being modified.

        Abigail

[reply]

In Section Seekers of Perl Wisdom