Q: Is pg_stat_activity data kept in Postgres over time, or is it sampled here and then discarded?

pg_stat_activity is a live, in-memory view — it shows the state of every backend process at the exact moment you query it, and nothing more. Postgres does not persist it, log it, or keep any history of it. The moment a session ends or a query finishes, its row is gone from the view.

You query pg_stat_activity
        │
        ▼
Postgres reads live state from shared memory → returns current rows
        │
One second later the same query returns entirely different rows.
No record of what was there before.

What Azure does is periodically sample that live view and ship the results to Log Analytics, which is what gives you historical data. Log Analytics retains those rows according to the workspace retention policy (default 30 days, configurable up to 730 days).

Postgres server                        Azure Log Analytics
─────────────────                      ───────────────────
pg_stat_activity  ──(sample every 5min)──▶  AzureDiagnostics
  (live, no history)                        (historical, retained)

pg_stat_statements and Query Store data are persisted on the server itself (in the azure_sys database), but it is still Azure's diagnostic pipeline that ships them to Log Analytics for historical querying.

Q: Since sampling is done every 5 minutes, does that mean a lot of pg_stat_statements content is never logged?

No — but the answer depends on the category. Each one collects data differently.

pg_stat_activity is a live view — you either catch a session in the snapshot or miss it. The 5-minute cadence of PostgreSQLFlexSessions loses a lot: any session that connects, runs, and disconnects between two snapshots is invisible.

pg_stat_statements is a cumulative accumulator. Every time any query finishes, Postgres atomically adds its stats to the running counters — regardless of whether any agent is watching. Azure reads the delta at the end of each 15-minute window. Calls_d = 10,000 means exactly 10,000 executions happened — none are missed.

Query executes and finishes
        │
        ▼
pg_stat_statements counters for this Queryid:
  calls     += 1
  total_time += <duration>
  rows       += <rows>
  blks_hit   += <hits>
  …  (atomic, on every execution, no monitoring agent needed)

every 15 min:
  Query Store reads delta → stores in azure_sys (no loss)
  Azure ships azure_sys  → Log Analytics     (no loss)

Summary across all categories:

Q: What does "Log Analytics ingestion" cost mean, and when do I actually get charged?

When you configure a Diagnostic Setting on the Postgres Flexible Server and point it at a Log Analytics workspace, Azure streams the enabled log categories into that workspace. Log Analytics charges for the data it receives — this is the ingestion cost, billed per GB of raw log data that flows in.

You pay when all three of these are true simultaneously:

1. A Diagnostic Setting exists on the server pointing to a Log Analytics workspace.
2. The paid category is enabled in that setting (e.g. PostgreSQLFlexSessions is checked).
3. The server is actually producing data for that category (e.g. there are active sessions to snapshot).

If any one of the three is false — no setting, category disabled, or no data generated — you pay nothing for that category.

PostgreSQLLogs is a special exception: Microsoft made it free at the ingestion level because it is the basic operational log every server needs. All other categories incur the standard Log Analytics ingestion rate (~$2–3 per GB depending on region and commitment tier, with the first 5 GB/month per billing account free).

Retention is a separate charge: the first 30 days in a Log Analytics workspace are included; beyond that, you pay per GB per month for extended retention.

Diagnostic Setting enabled
        │
        ▼
Data flows to Log Analytics workspace
        │
        ▼
Ingestion billed per GB  (except PostgreSQLLogs → free)
        │
        ▼
Retention billed per GB/month after 30 days

In practice the biggest cost driver is PostgreSQLFlexQueryStoreRuntime and PostgreSQLFlexSessions on a busy server — they produce the most volume. PostgreSQLFlexDatabaseXacts and PostgreSQLFlexPGBouncer tend to be very small.