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.

Best regards,


On 08/05/2017 04:50 PM, Phil Stracchino wrote:
Rather than re-opening the ticket again - the schema patch doesn't do
NEARLY as much as it looks as though it does.

The make_mysql_tables script currently creates a new Bacula schema in
which all DATETIME fields *except one* are left as unadorned DATETIME
with no NOT NULL or DEFAULT.  The one exception is the DATETIME field in
Snapshot, and we talked about that and you agreed the NOT NULL was
unnecessary.  So the patch removes it, so that the column is not
declared NOT NULL without a default.

The Snapshot table also contains one BIGINT declared NOT NULL without a
DEFAULT, which is invalid.  The patch adds a DEFAULT 0 to that column.

Those are the only changes made to make_mysql_tables.in.  One NOT NULL
removed, one DEFAULT added.

The change to update_mysql_tables.in does only one thing:  It makes all
the DATETIME columns in an *existing* Bacula catalog database match the
DATETIME columns in a brand new one created by make_mysql_tables.  (It
should also fix the missing DEFAULT on Snapshot.CreateTDate, but I just
realized this morning I missed that.)

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

Reply via email to