Plan selection cost models: usage over time (cost model 1), peak capacity (cost model 2), own-cluster trade-offs (cost model 3) #683

Context: what plan selection's memory price actually covers

#682 adds a memory price to plan selection (Stage 3): cost_per_retained_byte × peak_memory_bytes() of every operator. That includes aggregation state, sort and window buffers, hash-join builds and PromQL range buffers (series × window samples × width). It is charged once per computation and scaled by the per-consumer multiplier.

This is consistent with how CPU is charged, and it doesn't double count against scanned bytes. But calling it "retained bytes" is wrong; it is peak memory per computation, all operators. It is also what moves Example 2's selected total from 86.4 to 134.4: range-buffer memory, not exact state. Descriptions and docs must say this accurately. (#682's description is being corrected; the doc wording belongs to #677.)

More generally, plan selection uses a single cost formula (analytical_cost with illustrative prices). Deployments pay for resources in different ways, so plan selection should support several cost models and let the deployment pick one.

Proposed cost models

Notation: for one candidate plan over the workload's horizon, CPU(t), mem(t) and disk(t) are its resource usage over time, and w1, w2, w3 are the deployment's prices.

Cost model 1: usage over time (pay-as-you-go)

cost = w1 · AUC(CPU) + w2 · AUC(mem) + w3 · AUC(disk)

AUC is the area under the usage curve: CPU-seconds, GB-seconds of memory, GB-months of disk. This matches serverless and pay-per-use cloud billing, where you pay for what you use while you use it.

Cost model 2: peak capacity (provisioned)

cost = w1 · max(CPU) + w2 · max(mem) + w3 · max(disk)

You pay for the capacity you provision, and you must provision for the peak. This matches reserved or provisioned instances, fixed-size clusters, and Kubernetes requests and limits.

Cost model 3: the deployment's own cluster (no prices)

Report, per candidate, the total memory required, the total disk space required and the latency guarantee, and let the deployment choose under its fixed memory and disk capacity and its latency requirement. This is a set of trade-offs, not a single number. Its details are tracked in #660.

Survey: how cloud billing maps to these models

To do: confirm each against the provider's current pricing docs, then use them to set defaults or presets for w1–w3. The dimensions below are what matter; prices change.

Cost model 1 (usage × time):

• Serverless compute bills vCPU-seconds and memory GB-seconds directly: AWS Fargate, Google Cloud Run, AWS Lambda (GB-seconds, with CPU scaled by memory), Azure Functions (GB-seconds). This is exactly w1·AUC(CPU) + w2·AUC(mem).
• Object and block storage bill GB-months (AUC of disk), plus per-request charges: S3, GCS and Azure Blob for objects; EBS and Persistent Disk for provisioned volumes, where the provisioned size counts.
• Query engines:
  • BigQuery on-demand bills bytes scanned, a separate dimension that the current plan selection already prices as scanned bytes; BigQuery editions bill slot-hours, which is AUC of capacity.
  • Snowflake bills credits per second of warehouse runtime, where the warehouse size is a fixed capacity. It is a hybrid: AUC of a capacity step.
  • Athena and Redshift Spectrum bill bytes scanned.
• Managed streaming and metrics services bill ingestion volume, storage over time and query or scan volume (Amazon Managed Service for Prometheus: samples ingested, storage, query samples processed). This is closest to an ASAP deployment.

Cost model 2 (peak capacity):

• VMs and reserved instances (EC2, GCE, Azure VMs): you pick an instance size for the peak CPU and memory and pay for it whether you use it or not.
• Provisioned clusters (Redshift provisioned, Kafka/MSK brokers, Flink/Kinesis Data Analytics KPUs, Databricks clusters (DBUs × cluster size), Kubernetes node pools): the size is chosen for the peak load.
• Provisioned storage (EBS, Persistent Disk): you pay for the provisioned size, i.e. max(disk).

Cost model 3 (own cluster): no billing. Capacity is fixed, so the question is whether a plan fits, and at what latency (#660).

Requirements for plan selection

• Usage over time per candidate. Plan selection already estimates CPU, scanned bytes and peak memory per operator. Cost model 1 also needs how long each piece of state is held. For example, state materialized at ingestion time (Stage 2 materialization, Stage 2 materialization: ingestion vs query time per summary #604) is held for its retention, while a query-time computation's state is held only during the evaluation. Recurrence (Stage 3 per-second cost model, memory pricing and calibration #594, G4) gives evaluations per second.
• Peak usage per candidate. Cost model 2 needs concurrent peaks, which are not the same as per-computation peaks: overlapping evaluations and ingestion-time state that is always resident.
• Memory vs disk. The medium in Materialization::{MatAtIngestion, MatAtQuery}(Medium) decides whether stored state counts as memory or as disk.
• Choice of model. The cost model and its prices (w1–w3) are deployment inputs (G9, Deployment inputs: capabilities and raw-data retention #609). The planner stays deployment-agnostic.
• Output. Plan selection reports each candidate's resource breakdown (AUC and peaks per resource) and which cost model priced it. The stage_pipeline output and the viewer (G11) show it.

Done when

• Plan selection can price candidates with cost model 1 or 2 from a deployment input, and report cost model 3's trade-offs (Stage 3: memory, disk and latency trade-offs per candidate, and cost models beyond cloud billing #660).
• Example 4 (materialization: ingestion vs query time) shows the different choices under cost model 1 and cost model 2.
• The cloud billing survey above is confirmed and recorded as presets.

Related: #682 (memory price), #660 (cost model 3: own cluster), #594 (per-second cost, G4), #604 (materialization, G8), #609 (deployment inputs, G9), #679 (measured costs), #671 (planning roadmap).