Re^2: Batch Upload/Insert – Row wise with Perl DBI

Very nice. This resulted in a 20x speed up of some code I was working with, loading daily batches into a table with a large amount of history. Blocks of 10000 lines were taking 150s give or take and with this change now complete in 7s.

I was looking for details on Oracle syntax for batch inserting so that I could really make my code look very ugly in the name of performance. This will do nicely instead.

Comment on Re^2: Batch Upload/Insert – Row wise with Perl DBI

Replies are listed 'Best First'.
Re^3: Batch Upload/Insert – Row wise with Perl DBI by Marshall (Canon) on Mar 23, 2012 at 01:45 UTC
Thanks for sharing your success with us! I have seen similar or even greater performance increases, see: Re^3: Efficient way to handle huge number of records? for a more recent benchmark. In this benchmark, the code started on Friday afternoon and runs until early on Sunday morning. Improved code runs in 3 minutes! And that's just for one 1 million row table! This matters and I am very, very sure about it! I mean couple of minutes versus couple of days! Current version of this code imports 5,740,776 rows into 8 tables and runs in less than 10 minutes on my slow machine. The production machine will run this much faster. In my application, this is "fast enough". This is a case where there is a LOT of low hanging fruit and its easy to get it if you know how! 20x performance increase is nothing to be sneezed at! The next level of performance is how the DB deals with indicies. It is faster to create the indicies after the complete table is built. Getting that next level is harder than the first, most important level. I congratulate you for your success and also reporting back after some months with the results. This helps others and that is what this forum is about.	[reply]

Replies are listed 'Best First'.

Re^3: Batch Upload/Insert – Row wise with Perl DBI
by Marshall (Canon) on Mar 23, 2012 at 01:45 UTC

I have seen similar or even greater performance increases, see: Re^3: Efficient way to handle huge number of records? for a more recent benchmark. In this benchmark, the code started on Friday afternoon and runs until early on Sunday morning. Improved code runs in 3 minutes! And that's just for one 1 million row table! This matters and I am very, very sure about it! I mean couple of minutes versus couple of days!

Current version of this code imports 5,740,776 rows into 8 tables and runs in less than 10 minutes on my slow machine. The production machine will run this much faster. In my application, this is "fast enough".

This is a case where there is a LOT of low hanging fruit and its easy to get it if you know how! 20x performance increase is nothing to be sneezed at!

The next level of performance is how the DB deals with indicies. It is faster to create the indicies after the complete table is built. Getting that next level is harder than the first, most important level.

I congratulate you for your success and also reporting back after some months with the results. This helps others and that is what this forum is about.

[reply]