[GitHub] [arrow-datafusion] kmitchener commented on issue #5205: use more than one core/thread when querying CSV

["kmitchener (via GitHub)" <gi...@apache.org>]

kmitchener commented on issue #5205:
URL: https://github.com/apache/arrow-datafusion/issues/5205#issuecomment-1420038954

   
   > I definitely think a first step would be to interleave the fetching of the next set of bytes and decoding. This might be as simple as adding `buffered(1)` to the stream returned by `object_store` and polling it every call to `poll_fn`. I'd be happy to get a PR up to do this, if you'd be willing to help test it out (I don't have any realistic CSV workloads)
   
   Sure, of course, I'll be happy to test out any patches.
   
   > > I had an idea to try to implement some kind of fan-out/fan-in somewhere under CsvExec so that one thread is just reading from disk and sending the raw bytes to other threads to decompress/csv_read/convert to recordbatches
   > 
   > Doing this correctly is quite tricky as CSV permits unescaped newlines, which makes it actually impossible to know where a given record starts without having read all prior records, you can't just seek to the next newline character as that might be part way through a record.
   > 
   > That being said, a trick that I believe duckdb uses is to search for the next newline, and then test the first record against the expected schema, if it matches you have likely found a newline from which you can start reading.
   
   Ah, yes. I was thinking of using the function you already made for something similar: `newline_delimited_stream`. It could at least help move the CSV-parsing -> recordbatch to other threads, if not decompression. CSV-parsing is the largest part of the work. But after playing with it for a while, I'm pretty sure this is beyond my capabilities.
   
   > > 5 minutes per query isn't too unexpected (when uncompressed, it's a 100 GB file, 45 million records x 242 columns)
   > 
   > Not to blow my own trumpet, but I'm pretty chuffed by this, 2.7Gbps on a single core is pretty sweet 😁 We can and should make it even faster, but I think this is already pretty cool.
   
   Yeah, it's pretty great :) for a simple `select count(*) ..` query, current DF is faster than duckdb against my large test file. About twice as fast.
   
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org