westonpace commented on issue #34313: URL: https://github.com/apache/arrow/issues/34313#issuecomment-1442300222
> I think id < 12345 actually scans two row groups, the correct result for CountRows should be 20000 Shouldn't the correct result be 12344? > For Parquet's predicate pushdown, is the filter level row group or page? Row group level currently. Page level would be ideal but has not been implemented yet. > If it's row group, would the filtering level of the page be more efficient? Yes, in most cases, and there is no reason we can't do both. > If it's page, can ParquetFileFormat::CountRows accurately calculate the number of rows corresponding to the predicate expression? Depends. If the predicate affects multiple columns like `x < 10 && y > 0` then page indices can't fully answer the question. If the predicate only touches one column like `x < 10` then we still probably have to do some in-memory filtering (e.g. a page might have min=0 and max=20). > And where is the key code about the above questions? There are three main spots. First, the parquet-cpp library is a (mostly) standalone library for reading parquet files. It doesn't really have access to arrow expressions or arrow compute. Page indices would probably first be added at this level. Second, the arrow parquet reader wraps parquet-cpp and interfaces it with the rest of the arrow code. Any capability we add in parquet-cpp will need to be exposed through the arrow parquet reader. Finally, the parquet file format translates format-agnostic filtered reads into actual commands into the arrow parquet reader. Once the capability to do filtered reads has been added to the arrow parquet reader then the parquet file format will need to utilize this. -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
