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. ...
The next version of HTTP moves from TCP to QUIC, a transport with its own reliability built on UDP. The payoff is that packet loss on one stream no longer stalls the whole connection the way it can on TCP with HTTP/2. ...
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. ...
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 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. ...
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. ...
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. ...
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. ...