**Describe the situation**

```
SELECT * FROM test.hits INTO OUTFILE 'dump.csv' FORMAT CSV

8873898 rows in set. Elapsed: 32.487 sec. Processed 8.87 million rows, 8.46 GB (273.15 thousand rows/s., 260.42 MB/s.)
```

is bounded by single CPU core. Too slow :(
this_query_end = this_query_begin;
    try
    {
        parsed_query = parseQuery(th all_queries_end, true
    }
    catch (Exception & e)
    {
        current_exception.emplace(e
        return MultiQueryProcessingStage::PARSING_EXCEPTION;
    }
    if (!parsed_query)
    {
        if (ignore_error)
        {
            Tokens tokens(this_query_begin, all_queries_end
            IParser::Pos token_iterator(tokens, global_context->getSettingsRef().max_parser_depth
            while (token_iterator->type != TokenType::Semicolon && token_iterator.isValid())
                ++token_iterator;
            this_query_begin = token_iterator->end;
            return MultiQueryProcessingStage::CONTINUE_PARSING;
        }
        return MultiQueryProcessingStage::PARSING_FAILED;
    }
    // INSERT queries may have the inserted data in the query text
    // that follow the query itself, e.g. "insert into t format CSV 1;2".
    // They need special handling. First of all, here we find where the
    // inserted data ends. In multy-query mode, it is delimited by a
    // newline.
    // The VALUES format  more handling -- we also allow the
    // data to be delimited by semicolon. This case is handled later by