Use default value for decimal precision in parquet writer when not specified

[devavret]

Fixes #9962

[devavret]

After fixing the missing decimal precision, this still fails with Benchmark did not read the entire table. I think the logic to determine row_groups is improper.

cudf/cpp/benchmarks/io/parquet/parquet_reader_benchmark.cpp

Line 117 in ce02856

auto const num_row_groups = data_size / (128 << 20);

because

1. It uses 128 MB hardcoded
2. Row group is no longer fixed to being 128 MB with [FEA] Control rowgroup and page size when writing Parquet files #9615
3. Even if it was fixed, there is no guarantee the row groups will be data size/128 MB because 128 MB is still just an upper limit. There can be more row groups.

I'm thinking the fix could be that we add a libcudf API to read metadata. But this could take longer.

Apart from this failure, I see some more in the benchmarks for row_selection::NROWS. I think we should just disable ParquetRead/row_selection benchmarks for now.

cc @vuule

[hyperbolic2346]

Overall this change seems fine, but it sounds like there is more work to be done here as always.

[hyperbolic2346]

Suggested change

	for (cudf::size_type c = 0; c < view.num_columns(); ++c) {
	for (auto c = 0; c < view.num_columns(); ++c) {

This might read easier.

[vuule]

I'm fine with temporarily disabling the row_selection benchmarks 👍

Why does the writer require precision to be manually specified? Can we default to the max precision for the input decimal type?

[devavret]

Can we default to the max precision for the input decimal type?

I think this was avoided because there were some spark rules that limited precision based on decimal type width. And I figured all other libcudf users might not agree with those rules. The precursor to the precision setting in table_input_metadata was a writer option and that also threw when precision wasn't specified. @hyperbolic2346 would know why.

Although it wouldn't hurt because precision is merely a schema thing. It doesn't affect the data written into the pages, which are still the underlying rep.

[codecov]

Codecov Report

Merging #9963 (0e55611) into branch-22.02 (967a333) will decrease coverage by 0.03%.
The diff coverage is n/a.

@@               Coverage Diff                @@
##           branch-22.02    #9963      +/-   ##
================================================
- Coverage         10.49%   10.45%   -0.04%     
================================================
  Files               119      119              
  Lines             20305    20417     +112     
================================================
+ Hits               2130     2134       +4     
- Misses            18175    18283     +108     

Impacted Files	Coverage Δ
python/custreamz/custreamz/kafka.py	29.16% <0.00%> (-0.63%)	⬇️
python/dask_cudf/dask_cudf/sorting.py	92.30% <0.00%> (-0.61%)	⬇️
python/cudf/cudf/__init__.py	0.00% <0.00%> (ø)
python/cudf/cudf/core/frame.py	0.00% <0.00%> (ø)
python/cudf/cudf/core/index.py	0.00% <0.00%> (ø)
python/cudf/cudf/io/parquet.py	0.00% <0.00%> (ø)
python/cudf/cudf/core/series.py	0.00% <0.00%> (ø)
python/cudf/cudf/utils/utils.py	0.00% <0.00%> (ø)
python/cudf/cudf/utils/dtypes.py	0.00% <0.00%> (ø)
python/cudf/cudf/utils/ioutils.py	0.00% <0.00%> (ø)
... and 17 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a4dc42d...0e55611. Read the comment docs.

[devavret]

rerun tests

[devavret]

@gpucibot merge