Fix parquet reader batch size calculation

[kabunchi]

Description

Fixed regression in calculation of maxBytesPerCell that
caused maxBatchSize to be small and degrade performance

Non-technical explanation

Fixes possible perf regression in parquet reader introduced by a change in #13757

Release notes

( ) This is not user-visible 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
* Fix regression in performance of reading parquet files. ({issue}`14094`)

[sopel39]

Could you elaborate on regression that it fixes?

[kabunchi]

The issue here, is that since we didn't kept the maxBytesPerCell, we always assumed we hit the max and called this line :
maxCombinedBytesPerRow = maxCombinedBytesPerRow - maxBytesPerCell.getOrDefault(fieldId, 0L) + bytesPerCell;
over and over while maxBytesPerCell.getOrDefault(fieldId, 0L) always returned zero.
Following that we miscalculated the maxBatchSize to be lower than needed.
That causes significant larger number of getNextPage calls from this pageSource.

[skrzypo987]

Is it possible to write a unit test that shows the regression?

[raunaqmorarka]

Is it possible to write a unit test that shows the regression?

@kabunchi could you try testing this by checking size of pages produced by ParquetReader#nextPage ?

[kabunchi]

Took a look at testing, not that simple as the batch size is not fixed and/or exposed so predicting the page sizes or number of pages is not trivial...