Create a config param and session properties for setting Parquet's max read block row count

[assaf2]

Description

Lately (#15257) we increased the hard-coded value from 1k to 8k, but in some cases, 8k is much worse than 1k. A larger value may spare some CPU time but can also lead to more lazy block decoding, inputDataSize increase, and significant query performance degradation.
In the future, this param should be adaptive.

The following query took 36.83s on 403 and now it takes 59.76s (when max vector length is 8k):
SELECT count(c_description60) FROM storesalesflat_mixed WHERE ss_customer_sk>64992484;
The table is based on tpcds and contains 10,678,104,288 rows:

 CREATE TABLE hive.perf.storesalesflat_mixed (                    
    ss_sold_date_sk integer,                                      
    ss_sold_time_sk integer,                                      
    ss_item_sk integer,                                           
    ss_customer_sk integer,                                       
    ss_cdemo_sk integer,                                          
    ss_hdemo_sk integer,                                          
    ss_addr_sk integer,                                           
    ss_store_sk integer,                                          
    ss_promo_sk integer,                                          
    ss_ticket_number bigint,                                      
    ss_quantity integer,                                          
    ss_wholesale_cost double,                                     
    ss_list_price double,                                         
    ss_sales_price double,                                        
    ss_ext_discount_amt double,                                   
    ss_ext_sales_price double,                                    
    ss_ext_wholesale_cost double,                                 
    ss_ext_list_price double,                                     
    ss_ext_tax double,                                            
    ss_coupon_amt double,                                         
    ss_net_paid double,                                           
    ss_net_paid_inc_tax double,                                   
    ss_net_profit double,                                         
    d_date date,                                                  
    d_year integer,                                               
    d_quater integer,                                             
    t_am_pm char(2),                                              
    c_description100 varchar(100),                                
    c_string_num varchar(4),                                      
    c_town varchar(15),                                           
    c_description200 varchar(300),                                
    c_jibrish30 varchar(30),                                      
    c_description60 varchar(60)                                   
 ) 

Release notes

( ) This is not user-visible or docs only and no release notes are required.
( ) Release notes are required, please propose a release note for me.
(x) Release notes are required, with the following suggested text:

# Hive, Iceberg, Delta
* Allow configuring batch size for reads on parquet files. The configuration property `parquet.max-read-block-row-count` or the catalog session property `parquet_max_read_block_row_count` can be used for this. ({issue}`15474`)

[skrzypo987]

What's wrong with using parquet.max-read-block-size to limit the page size if indeed there is a regression?

Can you also share some info about the regressing query. I somehow don't see how this could significantly increase inputDataSize, as it tackles the reader's output.

[raunaqmorarka]

What's wrong with using parquet.max-read-block-size to limit the page size if indeed there is a regression?

Can you also share some info about the regressing query. I somehow don't see how this could significantly increase inputDataSize, as it tackles the reader's output.

parquet.max-read-block-size is quite hard to tune since it includes size of the data, row-count is straightforward thing to understand the impact of.
Regressing query has the pattern SELECT expensive_to_decode_column FROM table WHERE (selective predicate on another column).
It's a specific scenario where there are a small number of rows surviving from the filter for every few thousand input rows. When batch size is small, there are more lazy block which don't need to be loaded, when batch size is big chances increase that you need to load the whole lazy block just to get a few rows out of it.