Measure split listing time per table per query.

[Dith3r]

Description

Address issue #13921. Adds split distribution per table and per query.

Example output:

"stageStats": {
        "schedulingComplete": "2022-10-27T11:25:04.939Z",
        "getSplitDistribution": {
            "count": 1.0,
            "total": 6792.0,
            "p01": 6792.0,
            "p05": 6792.0,
            "p10": 6792.0,
            "p25": 6792.0,
            "p50": 6792.0,
            "p75": 6792.0,
            "p90": 6792.0,
            "p95": 6792.0,
            "p99": 6792.0,
            "min": 6792.0,
            "max": 6792.0,
            "avg": 6792.0
        },
        "tableGetSplitDistribution": [
            {
                "planNodeId": "0",
                "splitDistribution": {
                    "count": 1.0,
                    "total": 6792.0,
                    "p01": 6792.0,
                    "p05": 6792.0,
                    "p10": 6792.0,
                    "p25": 6792.0,
                    "p50": 6792.0,
                    "p75": 6792.0,
                    "p90": 6792.0,
                    "p95": 6792.0,
                    "p99": 6792.0,
                    "min": 6792.0,
                    "max": 6792.0,
                    "avg": 6792.0
                }
            }
        ]
    }

Non-technical explanation

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.
( ) Release notes are required, with the following suggested text:

[sopel39]

please check manually that it reports stats correctly (please paste an example)

[sopel39]

The next step is to expose is via io.trino.spi.eventlistener.QueryStatistics (can be separate PR)

[findepi]

Address issue #13921. Adds split distribution per table and per query.

How will it be available?

[sopel39]

How will it be available?

@findepi Event listener

[sopel39]

@Dith3r is this ready for review?

[Dith3r]

After merging #14785 I will update this PR. There are few changes.

[raunaqmorarka]

As a separate commit/PR, we can also update PlanPrinter to print this information for table scans in EXPLAIN ANALYZE VERBOSE

[raunaqmorarka]

I'm wondering what do we gain by knowing the distribution of get-splits time per table scan instead of the simpler cumulative time taken for get-splits per table scan ?
One file listing operation might feed multiple batches of splits, so it's possible that the distribution will just capture a few high values and many low values.

[Dith3r]

With distribution, we have information about total time needed for getting splits, count, and information if there are some outliers splits.

[raunaqmorarka]

My concern is that some get-split batches having an outlier time taken could be normal and then it wouldn't be clear what insight we might get from having a distribution.
Could you check what kind of results we get on an unpartitioned table with large number of files and a partitioned table with lots of partitions ?

[raunaqmorarka]

In hive connector, splits are loaded by the connector in a background thread (See BackgroundHiveSplitLoader), so recording time taken here will probably miss the actual work done in listing files by the hive connector.
@sopel39 maybe we need to extend ConnectorSplitSource to allow connector to provide metrics about split generation.