First, yes, I used DBD::SQLite and got the results described. Individual inserts are obviously faster than rewriting a flat-file every time you want to add something. And queries are very fast. But the act of doing 3000 inserts is a lot slower than writing a plain old flat file. Nothing surprising there; obviously writing a flat file should be quicker on a one-shot deal. But the point that I took from the OP's question was that he was creating a joined file from two separate files, and wanted to do so quickly. While maintaining a database efficiently is probably faster than maintaining a flat file, he seemed to be concerned with the creation time, not the ongoing maintenance time.

To answer your question about the hard-coded undef, check the documentation for SQLite. My first column in the table is an ID column, of type, "INTEGER PRIMARY KEY". I didn't mention this before because it was irrelevant to the discussion. The SQLite documentation states that this field can be populated with an autoincrementing unique index number, and to do so, all you have to do is insert a NULL value into that column, and SQLite will handle the rest. ...And a good way to insert NULL using DBI is to insert undef.

To your point, it might have been better to use undef in that field of my $sth->prepare() method call instead of one additional placeholder, but the speed gain is truly minimal. Adding one more placeholder isn't my code's bottleneck (I know because I initially created a similar database a couple days ago without the ID field and witnessed similar creation time).

C.