Hello again,
After realizing the obvious implementation flaws, I thought of a new idea and
again, would appreciate some feedback on the efficiency benefits.
My last post involved INSERT vs UPDATE efficiency. Neither is going to be a
directly useful approach. With 48k records and growing for just one table of 2, the
dump time was significantly too slow.
Here is my new idea. Instead of directly communicating with MySQL, how much more
efficient would it be to write the same statements to a text file, and then fork a
child thread to connect to the database, and read the entire infile at once? There is
some optimization for this , in addition to which writing the text file should only
take a few seconds since it's a strict out stream write.
Obviously this would increase performance of the client which dumps the text file,
and also give an intermediary level of preventing data loss, if the import didn't go
for some unpredictable reason, the file could still be imported prior to restarting
the application. Has anyone used this sort of method, does it pose any issues I
haven't considered?
I also realized I am running 4.0.10-gamma, precompiled for FreeBSD packages. I will
be compiling 4.0.13 with linuxthreads to gain any benefits there as well.
Thanks,
-Shane
p.s. I always find a last question. Off topic, compiled properly for each machine,
would MySQL run better on a quad ppro 200 (IBM PC704), or a similarily stocked 2.5ghz
P4 single processor system? Curious for expected results on a new development server
versus production server.
