ores.compute.grid_sample

Table of Contents

One snapshot of the grid, written by the compute service's poller on its own interval. The counters mirror what the database holds at that moment, so a dashboard reads one stored row rather than aggregating on every refresh.

The table is append-only and carries no validity window: a sample is a fact about an instant, and nothing edits it. That is why the model states :current_state:, which drops the transaction-time pair the bi-temporal shape would add and lets the partition column sit in the primary key.

The reads the codegen cannot express live beside it. A per-node newest row is a DISTINCT ON (host_id) and the live summary is a call to ores_compute_grid_stats_fn, so both stay hand-written in compute_telemetry_repository.

A sample describes the installation's own grid, not one tenant's slice of it, so the table carries :rls_own_or_system_tenant_rows:: every session reads the system tenant's rows, and writes stay the current tenant's. The C++ read states :tenant_read_scope: shared, so it adds no tenant predicate and the policy decides.

1. Flags

2. Columns

2.1. id

Surrogate key. A hypertable's partition column must sit in the primary key, and a surrogate key lets it do so without the tenant joining the key.

2.2. sampled_at

When the sample was taken.

2.3. party_id

The party whose work the row counts. NULL for work with no party, which predates the party scope. The poller writes one row of job counters for each tenant and each party that has work, all at one instant, so a session that reads the rows it may see sums them for a tenant or for the parties it acts for.

2.4. total_hosts

Total registered hosts.

2.5. online_hosts

Hosts whose last heartbeat is inside the reaper window.

2.6. idle_hosts

Online hosts with no result in flight.

2.7. results_inactive

Results in server state 1.

2.8. results_unsent

Results in server state 2.

2.9. results_in_progress

Results in server state 4.

2.10. results_done

Results in server state 5.

2.11. total_workunits

Workunits the tenant holds.

2.12. total_batches

Batches the tenant holds.

2.13. active_batches

Batches that are not closed.

2.14. outcomes_success

Results that finished with outcome 1 in the last day.

2.15. outcomes_client_error

Results that finished with outcome 3 in the last day.

2.16. outcomes_no_reply

Results that finished with outcome 4 in the last day.

3. C++

3.1. Repository

The grid rows describe the installation's fleet, not one tenant's slice of it, so the read states no tenant filter and the row-level-security policy is what decides. Mutations stay tenant-scoped.

3.2. Domain includes

#include <chrono>

3.3. Conventions

4. SQL

4.1. Flags

The newest read exists because the dashboard wants the last sample and a paged read walks the key from its oldest end. The retention policy keeps thirty days, which is what the hand-written table set. The installation's own rows are readable by every session the compute::grid_samples:read permission admits, and writes stay the current tenant's.

4.2. Indexes

name columns unique current_only where_extra
grid_samples_tenant tenant_id, sampled_at desc false false  

5. Physical space

The table is internal: the service writes it and the dashboard protocol reads it through the handler. Nothing reaches it over the wire, so only the data layer and the SQL schema are generated.

Address Enabled
ores.cpp.service false
ores.cpp.protocol false
ores.cpp.nats-handler false
ores.cpp.nats-sub-registrar false
ores.cpp.nats-event-registrar false
ores.cpp.nats-eventing false
ores.cpp.nats-event-cache false
ores.cpp.history-provider-registrar false
ores.cpp.presentation false
ores.cpp.eventing-integration-test false
ores.cpp.shell-command false
ores.sql.schema.notify_trigger false
ores.sql.schema.notify_trigger_drop false
ores.ts.protocol false
ores.ts.domain false

6. See also

Emacs 29.3 (Org mode 9.6.15)