[ 
https://issues.apache.org/jira/browse/PARQUET-1698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17014797#comment-17014797
 ] 

David Li commented on PARQUET-1698:
-----------------------------------

Probably there are a few layers:
* The file I/O layer should just expose a way for a consumer to hint at what 
ranges it's about to read; concurrency can be managed internally (we have some 
other optimizations around this though, like what Jacques describes - the 
implementation may choose to be more or less aggressive based on system 
resources, and readers globally cooperate to distribute bandwidth when scanning 
through a partitioned dataset).
* Readers need some way for consumers to hint what columns they actually want, 
as Wes described above, which translate into file I/O hints if the format makes 
this possible;
* Then at higher levels, we can pass down column hints from the Arrow or 
dataset read.

> [C++] Add reader option to pre-buffer entire serialized row group into memory
> -----------------------------------------------------------------------------
>
>                 Key: PARQUET-1698
>                 URL: https://issues.apache.org/jira/browse/PARQUET-1698
>             Project: Parquet
>          Issue Type: Improvement
>          Components: parquet-cpp
>            Reporter: Wes McKinney
>            Assignee: Zherui Cao
>            Priority: Major
>              Labels: pull-request-available
>             Fix For: cpp-1.6.0
>
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> In some scenarios (example: reading datasets from Amazon S3), reading columns 
> independently and allowing unbridled {{Read}} calls to the underlying file 
> handle can yield suboptimal performance. In such cases, it may be preferable 
> to first read the entire serialized row group into memory then deserialize 
> the constituent columns from this
> Note that such an option would not be appropriate as a default behavior for 
> all file handle types since low-selectivity reads (example: reading only 3 
> columns out of a file with 100 columns)  will be suboptimal in some cases. I 
> think it would be better for "high latency" file systems to opt into this 
> option
> cc [~fsaintjacques] [~bkietz] [~apitrou]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to