On Wed, Oct 19, 2011 at 11:11 AM, Henrik Ingo <[email protected]> wrote: >> Right. But the parser for that should not be server-side. >> Client can parse CSV (or XML or whatever) and generate normal SQL (or >> noSQL) statements. > > Yes, if you want to improve on what is currently there, I agree there > is room for improvement. But I don't see a pressing need to remove the > existing LOAD DATA [LOCAL] INFILE as long as there is not a > replacement.
Are security, code simplicity and good design reasons not good enough? > Regarding parsing: The way LOAD DATA LOCAL INFILE works currently, it > sends the CSV file to server and there it is stored in /tmp/, read, > parsed and fed directly into the table. Possibly this is more > efficient than if the client would rewrite CSV data into SQL INSERTs, > then the server has to parse the SQL anyway, and SQL is quite wordy. > LOAD DATA is very efficient, I've managed to get 100k rows inserted by > second (small rows). I'm not sure you can easily get that with > INSERTs, (but maybe if you combine a lot of rows into one INSERT). If you combine rows, CSV and SQL have the same wordy-ness :p SQL has some extra escaping and quoting though. > It seems to me ideally you could just modify the current code so that > it will never read a file from the server, but instead it could > consume CSV data coming in from the client without saving it as a > temporary file first. Why's that ideal? Due to performance? I think performance is good enough when doing the parsing client-side. If it's not, that performance should just be improved. Olaf _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
