nicolastakashi/prom-analytics-proxy

lib/pq is in maintenance mode — no new features, security fixes only. The cancellation path (new connection per cancel) is less reliable than pgx/v5, which handles cancellation over the existing connection using the same wire-protocol flow. pgx/v5 may provide better performance and additional features, while remaining backwards compatible. pgx/v5 is the current community standard for PostgreSQL in Go and is actively developed. https://devandchill.com/posts/2020/05/go-lib/pq-or-pgx-which-performs-better/

Context (*PostGreSQLProvider).Insert for the queries write path (internal/db/provider.go) batches by wrapping a prepared statement in a transaction and calling stmt.ExecContext once per row: tx, err := p.db.BeginTx(ctx, nil) stmt, err := tx.PrepareContext(ctx, `INSERT INTO queries (...) VALUES ($1, $2, ...)`) for _, q := range queries { ... stmt.ExecContext(ctx, ...) } stmt.Close() tx.Commit() This is O(N) network round-trips for a batch of N queries. Under load this contends with the read path for connection slots, and when the database is saturated the ingester surfaces errors like: ERROR msg="unable to insert query" err="copyin flush: pq: canceling statement due to user request" (The "copyin flush" phrase in that error is misleading — it's from lib/pq's prepared-statement protocol, not a real COPY.) Proposal Use pq.CopyIn for postgres bulk inserts. The shape is: tx, err := p.db.BeginTx(ctx, nil) stmt, err := tx.PrepareContext(ctx, pq.CopyIn("queries", "ts", "querypa

Context The default sort field for /api/v1/seriesMetadata is queryCount (descending), set in routes.seriesMetadata: params := db.SeriesMetadataParams{ ... SortBy: "queryCount", SortOrder: "desc", ... } This is a great default for the UI's "what's getting queried most" view. But for the specific filter ?usage=unused, by definition every row in the result set has query_count = 0. The ORDER BY COALESCE(s.query_count, 0) DESC still runs — the sort node materialises and sorts the entire pre-LIMIT result set even though it's not breaking any ties (the rows come back in physical order anyway, after a fully wasted sort step). For a high-throughput client that always sends usage=unused (e.g. a tooling layer that drops metrics deemed unused by the inventory), this is steady-state overhead with no observable benefit. Proposal When usage = "unused" and no explicit sortBy was supplied by the caller, default to name (which has a primary-key index — sort is a no-op against the

Currently "Alerts", "Records", "Dashboards" are populated only if prom-analytics-proxy is deployed together with Perses Metrics Usage. As this is not a strict dependency, we should introduce a toggle (maybe flag / config.yaml unless it's possible to autodetect it somehow) to show/hide "Alerts", "Records", "Dashboards" in "Metrics catalog" and "Metric details" pages. Below some screenshots. Metrics catalog Metric details

The root README is definitely too long, we should split it into multiple md files in docs/ directory. At the same time: we should improve the section Metrics Usage Integration specifying that Metrics Usage is not required (strict dependency) it's an enhancement providing X, Y, Z additional info how it combines with prom-analytics-proxy it would be good to improve also docs/ structure and hierarchy.