# 6.1.1 The Starvation (Client & Timeout)  In a performance-tuned database, it is often a surprise to find that the most frequent wait event is not I/O or locking, but simply the database waiting for the application. This is categorized as a **Client Wait**. ## The Illusion of Load: `ClientRead` When you see a high frequency of `Client:ClientRead` in `pg_stat_activity`, it means the backend process is healthy, but it is **Starved of Work**. The database has finished its last task and is now waiting for the application to send the next packet over the network. - **Frontend Bottlenecks**: If your application is doing heavy business logic between database calls, the database process sits idle, holding open its transaction resources. - **Network Latency**: In a distributed system, every round-trip between the app and the database adds "Starvation Time." A 10ms network delay on a sequence of 100 queries creates a 1 second overhead where the database is doing nothing but waiting. > [!IMPORTANT] > **The Starvation Trap**: A system with high Client waits is not overloaded. It is inefficient. You are paying for a high-performance engine that is spending most of its time waiting for the "staff" (your application) to bring it a new order. ## The Timeouts: Logical Termination To protect itself from clients that have stalled or crashed, Postgres uses **Timeouts**. These ensure that resources are not held indefinitely. - **`Timeout:IdleInTransactionSessionTimeout`**: This is a critical safety valve. If a client opens a transaction (`BEGIN`) but then stops sending commands, it holds an open **[[Chapter 1/1.4 - The Table (The Relation)|MVCC Snapshot]]**. This prevents **[[Chapter 5/5.3 - The Housekeepers (Vacuum & Freezing)|Autovacuum]]** from cleaning up dead tuples, leading to table bloat. - **`Timeout:LockTimeout`**: If a query is blocked by another process's lock for too long, it will eventually abort. This prevents "Deadlock Trains" where a single stuck process blocks the entire system. - **`Timeout:StatementTimeout`**: The hard limit on any single execution. If a query takes longer than this threshold (e.g., 30 seconds), the engine terminates it to prevent runaway resource consumption. Understanding Client and Timeout waits is the first step in recognizing that database performance is often a function of **Application Behavior** as much as it is a function of disk speed or CPU power. --- | ← Previous | ↑ Table of Contents | Next → | | :--- | :---: | ---: | | [[Chapter 6/6.1 - The Silence of the Engine (Wait Events)\|6.1 The Silence of the Engine (Wait Events)]] | [[Learn You a Postgres for Great Good\|Home]] | [[Chapter 6/6.1.2 - The Elephant Yell (IPC)\|6.1.2 The Elephant Yell (IPC)]] |