Push compute engine value loading down to tsdb codec

[martijnvg]

Evolution of #128334, but is targeted for just loading @timestamp and _tsid field values (tsid is missing and will be added soon) in the context of queries like:

TS metrics-hostmetricsreceiver.otel-default | WHERE `metrics.system.memory.utilization` IS NOT NULL AND @timestamp >= \"2025-07-31T08:58:00.000Z\" AND @timestamp <= \"2025-07-31T10:28:00.000Z\" | STATS AVG(AVG_OVER_TIME(`metrics.system.memory.utilization`)) BY host.name, BUCKET(@timestamp, 1h) | LIMIT 10000

Relates to #128445 and #132379

[martijnvg]

I benchmarked this change with the following query:

TS metrics-hostmetricsreceiver.otel-default | STATS COUNT(COUNT_OVER_TIME(`@timestamp`)) BY BUCKET(@timestamp, 1h) | LIMIT 10000

This change only optimizes loading of @timestamp and _tsid fields and the query in the description of pr also loads two other fields (host.name and metrics.system.memory.utilization). Loading these other fields now takes the majority of value source loading and so I'm using the query mentioned here to highlight the impact of this improvement.

Without this change default data partition on my local laptop the average query time after 36 executions is: 957 ms. Detailed profiling of value source operator using shard data partition:

{
    "operator": "ValuesSourceReaderOperator[fields = [@timestamp]]",
    "status": {
        "readers_built": {
            "@timestamp:column_at_a_time:BlockDocValuesReader.SingletonLongs": 59
        },
        "values_loaded": 221184000,
        "process_nanos": 713120339, --> ~713 ms
        "pages_received": 59106,
        "pages_emitted": 59106,
        "rows_received": 221184000,
        "rows_emitted": 221184000
    }
}

{
    "operator": "ValuesSourceReaderOperator[fields = [_tsid]]",
    "status": {
        "readers_built": {
            "_tsid:column_at_a_time:BlockDocValuesReader.SingletonOrdinals": 59
        },
        "values_loaded": 221184000,
        "process_nanos": 941064060, --> ~941 ms
        "pages_received": 59106,
        "pages_emitted": 59106,
        "rows_received": 221184000,
        "rows_emitted": 221184000
    }
}

With this change using default data partition on my local laptop the average query time after 36 executions is: 753 ms. Detailed profiling of value source operator using shard data partition:

{
    "operator": "ValuesSourceReaderOperator[fields = [@timestamp]]",
    "status": {
        "readers_built": {
            "@timestamp:column_at_a_time:TimestampBlockLoader.Timestamps": 59
        },
        "values_loaded": 221184000,
        "process_nanos": 250188096, --> ~250ms
        "pages_received": 59106,
        "pages_emitted": 59106,
        "rows_received": 221184000,
        "rows_emitted": 221184000
    }
}

{
    "operator": "ValuesSourceReaderOperator[fields = [_tsid]]",
    "status": {
        "readers_built": {
            "_tsid:column_at_a_time:TSIDBlockLoader.TSIDs": 59
        },
        "values_loaded": 221184000,
        "process_nanos": 244960319, --> ~245ms
        "pages_received": 59106,
        "pages_emitted": 59106,
        "rows_received": 221184000,
        "rows_emitted": 221184000
    }
}

The detailed profiling output seems to suggest that ~3 times improvement. Note that the profile data was captured with data_partitioning set to shard. Otherwise many more ValuesSourceReaderOperator and then results are not comparable between query executions.

That improvement isn't as visible in the overall query time, because still a big part of time spent is in HashAggregateOperator.

Flame graph with simplified query with this change: