Performance

Both upload rows pause after 1024 of 65536 bytes. Buffering on stops before backend-handler entry; buffering off forwards early and the handler reads one byte.

Request buffering controls when the backend receives an upload

An upload has two separate connections: client to nginx and nginx to the application. proxy_request_buffering on reads the complete client request body before sending that request upstream. Turning it off lets nginx forward body bytes as they arrive. This changes when the application becomes occupied; it does not create unlimited capacity or make a slow sender disappear. ...

QUIC stream A has already delivered a but is missing b. Stream B has complete xy and can deliver it while A waits. Recovery still has shared boundaries.

HTTP/3 separates stream delivery, not all recovery

HTTP/3 carries HTTP over QUIC instead of TCP. QUIC offers independently ordered streams, so a missing range in one stream need not prevent delivery of already received data on another. This removes a particular transport ordering dependency. It does not give each request a separate congestion controller, loss detector, or guaranteed completion time. ...

Three loops each supply two rows through the inner Limit, producing six joined rows. Row output is per loop; a LIMIT can also stop a child before full output is consumed. Article observations are illustrated, not rerun.

EXPLAIN estimates need execution context

EXPLAIN describes the plan PostgreSQL intends to execute. EXPLAIN ANALYZE executes that plan and adds measurements. Comparing them is useful only after interpreting what each number counts. An apparent mismatch can reflect stale estimates, repeated execution, or a parent that stopped requesting rows. Matching cardinalities strengthen one part of the model; they do not prove the chosen plan is the fastest possible plan. ...

One worker configured with keepalive 2 holds four active upstream connections, then retains two idle connections after release. Idle retention is not an active connection cap.

Upstream keepalive caches idle connections, not active capacity

An nginx upstream keepalive cache preserves eligible idle backend connections for later requests. In the tested configuration, keepalive 2 permits two idle connections in that upstream cache for each worker. It does not restrict the worker to two active backend connections. Reuse reduces repeated connection setup; it does not itself impose an application concurrency budget or guarantee lower latency for every request. ...

ANALYZE updates the estimates the planner relies on

ANALYZE updates the statistical model PostgreSQL uses to estimate query results. It does not rewrite the query, rebuild its indexes, remove dead tuples, or promise a faster plan. Its useful question is specific: does the planner understand the current distribution well enough to compare access paths? A bulk status change can invalidate that understanding even when the table still contains exactly the same number of live rows. ...

An application boundary contains one queued caller, a rejected caller and a holder; only the holder connects to the single pool backend.

A pool shares a few Postgres connections among many requests

A connection pool lets many application requests borrow a smaller number of PostgreSQL sessions over time. Reuse amortizes connection setup and limits simultaneous leases, but does not make an overloaded database faster by itself. The pool creates another queue whose capacity, waiting time, and cancellation behavior belong to the request budget. Treat that queue as part of the service, not as an invisible implementation detail. ...

An ordered branching B-tree silhouette contrasts with one hash bucket containing an equals sign.

Choose B-tree or hash from the required operations

PostgreSQL’s default B-tree index supports several common query requirements: equality, ranges, ordered access, and uniqueness enforcement. A hash index supports a narrower equality access path. Choosing between them starts with the required operators and constraints, then proceeds to measurement. Saying that hashes are always faster for equality, or that PostgreSQL almost never chooses them, replaces a workload question with an unsupported generalization. ...

Two sequential lease symbols loop through one retained physical connection.

Connection pools amortize slow setup

A connection pool amortizes setup across several uses of a physical connection. It does not make setup disappear, and creating a pool does not necessarily open anything. Distinguish the application’s short-lived lease from the underlying database connection: closing the former normally returns the latter for reuse. ...