On 30/10/2020 22:56, Tomas Vondra wrote:
I agree this design looks simpler. I'm a bit worried about serializing
the parsing like this, though. It's true the current approach (where the
first phase of parsing happens in the leader) has a similar issue, but I
think it would be easier to improve that in that design.
My plan was to parallelize the parsing roughly like this:
1) split the input buffer into smaller chunks
2) let workers scan the buffers and record positions of interesting
characters (delimiters, quotes, ...) and pass it back to the leader
3) use the information to actually parse the input data (we only need to
look at the interesting characters, skipping large parts of data)
4) pass the parsed chunks to workers, just like in the current patch
But maybe something like that would be possible even with the approach
you propose - we could have a special parse phase for processing each
buffer, where any worker could look for the special characters, record
the positions in a bitmap next to the buffer. So the whole sequence of
states would look something like this:
EMPTY
FILLED
PARSED
READY
PROCESSING
I think it's even simpler than that. You don't need to communicate the
"interesting positions" between processes, if the same worker takes care
of the chunk through all states from FILLED to DONE.
You can build the bitmap of interesting positions immediately in FILLED
state, independently of all previous blocks. Once you've built the
bitmap, you need to wait for the information on where the first line
starts, but presumably finding the interesting positions is the
expensive part.
Of course, the question is whether parsing really is sufficiently
expensive for this to be worth it.
Yeah, I don't think it's worth it. Splitting the lines is pretty fast, I
think we have many years to come before that becomes a bottleneck. But
if it turns out I'm wrong and we need to implement that, the path is
pretty straightforward.
- Heikki