Thanks Yufei
On Sat, Oct 18, 2025 at 1:42 AM Yufei Gu <[email protected]> wrote:
> 1. Metrics ingestion(write) REST API. Can we reuse the Iceberg IRC path
> /v1/{prefix}/namespaces/{namespace}/tables/{table}/metrics and extend it
> with a new payload type? I suggest we float this with the Iceberg community
> first, the interoperability benefits would be huge.
>
How do you suggest this would work for other entities than tables and other
formats than Iceberg (think: Generic Tables / Table Sources) ?
> 2. Metrics serving (read) REST API. This makes sense to me, but I’d also
> propose socializing the read side in the Iceberg community to avoid future
> conflicts. Given that a write endpoint is already defined, adding a read
> endpoint feels like the natural complement. One of recent examples is
> adding event endpoints[1][2].
>
Ditto
> 3. For table snapshot metrics derived from snapshot summaries, we should
> include snapshot_id and timestamp in the schema so the metrics are
> interpretable and time-bound.
>
Those fields as already stored as part of the `metrics_data` column.
> 4. The draft leans to OLTP (e.g., Postgres). Could we add more rationale on
> why OLTP was chosen over a TSDB (query patterns, retention, cardinality,
> cost/ops, backfill, downsampling)? Even a brief trade-off table would help.
>
The current proposal does not forbid the use of TSDB databases. This is
just another SPI implementation.
I wanna expand a bit on the Rest spec design. It's a huge win if we can
> avoid framegenentation between IRC and Polaris REST spec. I'd suggest
> looking into event API spec design[2], which provides a good example for
> predefined types and custom types[1]. The metric endpoint could take the
> same way to add a few common metric types to improve interoperability, and
> add custom metric types to allow Polaris specific or user specific metrics.
>
Why would an enum be added to the OpenAPI spec, given that there is already
an endpoint that lists all supported metrics, and that custom metrics can
already be added?
--
Pierre
