On 08/06/17 03:24, Kern Sibbald wrote: > Hello Phil, > > Thank you for your comments, and I am pleased that you have found a > solution for your batch insert problem. Unfortunately, I cannot apply > the patch to a released version two days before I go on vacation. Nor > will I change the default. > > If you can show me solid statistics on a Linux system that for the most > current MySQL inserting between 20 and 50 million records in a single > job is slower with batch insert than without it, I will ask the authors > of the code to take a look at it or at least explain. Otherwise, I > trust their judgment. That said, it may well be for smaller workloads > and a properly tuned MySQL it could be more efficient to do normal inserts.
I can't meet that criterion because I don't have a job that large to test against. My largest job has just under three million files. And to be fair I just switched out my main NAS for a more powerful system; that could easily be the reason for the better performance on incremental backups. I can say that large jobs run with steady incremental writes to the DB throughout the job instead of the massive choke-a-hippo attribute despool at the end of each job. Community request: Does anyone else here have a test environment which DOES have jobs of that size who could perform comparison tests of the same 20-50 million file backup job with and without batch insert? -- Phil Stracchino Babylon Communications ph...@caerllewys.net p...@co.ordinate.org Landline: +1.603.293.8485 Mobile: +1.603.998.6958 ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Bacula-devel mailing list Bacula-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-devel
