Inside the five-stage pipeline from 1.1.1, there is another fork right after the parser. PostgreSQL classifies every SQL command into one of two camps. One side holds the optimizable queries, the other holds the utility commands. The classification is decided by a single field on the Query node, commandType, and from that point on the two camps travel completely different paths. One goes through the rewriter, the planner, and the executor. The other bypasses all three.

This fork was a single line in the 1.1.1 picture, but it shapes the entire internal structure of PostgreSQL, so it earns its own section.

Five optimizables, and everything else

PostgreSQL defines its command types as a single enum.

typedef enum CmdType
{
    CMD_UNKNOWN,
    CMD_SELECT,
    CMD_UPDATE,
    CMD_INSERT,
    CMD_DELETE,
    CMD_MERGE,
    CMD_UTILITY,
    CMD_NOTHING,
} CmdType;

Of these, CMD_SELECT, CMD_INSERT, CMD_UPDATE, CMD_DELETE, and CMD_MERGE are the optimizable ones. As the name suggests, these are queries the planner can do meaningful work on. It rearranges join order using a cost model, picks indexes, and chooses scan methods.

CMD_UTILITY is the catch-all for everything else: CREATE TABLE, ALTER TABLE, DROP, VACUUM, BEGIN/COMMIT/ROLLBACK, COPY, NOTIFY, LISTEN, CLUSTER, REINDEX, GRANT, SET, SHOW, TRUNCATE, LOCK, FETCH, CHECKPOINT, PREPARE TRANSACTION, CREATE INDEX, CREATE FUNCTION, and many more. What they share is a single property: the planner has no room to produce a better plan via cost comparison.

A command like CREATE TABLE foo (id int) cannot have two different paths. It just inserts a few rows into the system catalog and asks the storage manager to allocate a new relfilenode. BEGIN similarly nudges the transaction state by one step; there is no choice in "how to BEGIN." VACUUM walks a target table page by page and cleans up dead tuples through a fixed procedure. The point is that cost comparison is meaningless here.

The two camps are wired through different code paths. The first split happens in the analyzer, right after the parser hands over a raw parse tree.

The fork lives in transformStmt's switch

When the raw parse tree arrives, transformStmt() runs a large switch on the node tag (src/backend/parser/analyze.c).

switch (nodeTag(parseTree))
{
    /* Optimizable statements */
    case T_InsertStmt:
        result = transformInsertStmt(...);
        break;
    case T_SelectStmt:
        result = transformSelectStmt(...);
        break;
    /* ... UPDATE, DELETE, MERGE ... */

    /* Special cases (utility wrappers around an optimizable inside) */
    case T_DeclareCursorStmt:
    case T_ExplainStmt:
    case T_CreateTableAsStmt:
    case T_CallStmt:
        /* transform the inner query separately */
        ...

    default:
        /* every other utility */
        result = makeNode(Query);
        result->commandType = CMD_UTILITY;
        result->utilityStmt = parseTree;
        break;
}

PostgreSQL does meaningful semantic analysis on the five optimizable statement types and a handful of special cases. Everything else falls through to the default branch, gets stamped commandType = CMD_UTILITY, and the raw parse tree is stored verbatim in the utilityStmt field. Nothing was actually analyzed; a Query shell was wrapped around the raw tree with a "this is utility" sticker.

The next stage, the rewriter, also reads that sticker (src/backend/tcop/postgres.c).

if (query->commandType == CMD_UTILITY)
    querytree_list = list_make1(query);   /* don't rewrite utilities */
else
    querytree_list = QueryRewrite(query);

If the query is utility, the rewriter does not touch it. The rule system, view expansion, and RLS policy application all live on the optimizable side and have no meaning for utility commands.

The planner is the same.

if (query->commandType == CMD_UTILITY)
{
    /* Utility commands require no planning. */
    stmt = makeNode(PlannedStmt);
    stmt->commandType = CMD_UTILITY;
    stmt->utilityStmt = query->utilityStmt;
    ...
}
else
{
    stmt = pg_plan_query(query, ...);   /* invoke the planner */
}

Utility commands never call into the planner. An empty PlannedStmt wrapper is built, and the raw parse tree is dropped into it. A PlannedStmt with no plan tree.

The executor stage is split too. Optimizable statements feed their plan tree into the executor proper, which produces rows. Utility statements get handed off to ProcessUtility(), which dispatches to a per-statement handler. The dispatch logic and the individual handlers belong to later chapters (DDL in 1.6, transaction commands in chapter 4).

When you lay out the four stages side by side, the asymmetry is sharp.

The whole sophistication of the planner exists for those five types; utility bypasses it entirely. This is not an efficiency choice. It is a structural asymmetry, because utility commands have no alternative paths to compare.

Two species sharing one system

Once you see how this asymmetry is wired, the two camps look almost like two species inside the same engine.

Hooks live on different paths. A hook in PostgreSQL is a function pointer exposed at a key point in the execution path so that external code (typically an extension) can plug in. An extension installs its own function address into the hook, and PostgreSQL calls it whenever the hook is non-null at the appropriate moment. Which camp the hook applies to depends on where it sits. planner_hook is invoked just before the planner runs, so it only affects optimizable queries. Utility never enters the planner, so planner_hook never fires for utility. On the other side, ProcessUtility_hook is invoked just before ProcessUtility() runs, so it only applies to utility commands. That is how an audit logging extension like pgaudit intercepts DDL and DCL. You need both hooks together to cover every SQL execution path. If you write extensions, you have to know up front which camp your hook is intercepting.

Statistics are split too. PostgreSQL accumulates usage patterns about which SQL ran how often and for how long, and DBAs use that data to find slow queries and pick tuning targets. The recording channels, however, are split between the two camps. pg_stat_statements records SELECT/INSERT/UPDATE/DELETE/MERGE executions along with plan-level information. Some utility commands (especially DDL) need a separate channel like log_statement = ddl. A monitoring tool that wants to draw "what is happening in this system" has to read both channels.

Prepared statements mean different things in each camp. The prepared statements from 1.1.2 cache plans for optimizable queries. Utility commands can be wrapped with PREPARE too, but since there is no plan, there is nothing to cache. The server just keeps the raw tree around and routes each EXECUTE through ProcessUtility again. Same name, different semantics.

EXPLAIN's reach is asymmetric. EXPLAIN SELECT ... draws a plan tree. EXPLAIN ALTER TABLE ... does not work; there is no plan tree to draw. The exception is the special-case group from the switch above (T_DeclareCursorStmt, T_ExplainStmt, T_CreateTableAsStmt, T_CallStmt). They are classified as utility on the outside but contain an optimizable query that goes through the regular pipeline. That hybrid path is why EXPLAIN ANALYZE INSERT INTO ... SELECT ... works. The outer wrapper is utility; the SELECT and INSERT inside are optimizable.

I once tried to debug "why is this long ALTER TABLE so slow" by analyzing the plan. The plan had no answer. The bulk of the cost lived outside the plan tree: lock waits, catalog updates, full-table rewrites, and WAL volume. That was when I learned why utility needs its own dedicated path. Some costs are invisible to the plan-level cost model, and to see them you need a different stage of tools.

What this means in practice

First, planner-related tuning and monitoring tools have no meaning for utility. EXPLAIN, plan-level metrics in pg_stat_statements, auto_explain, plan_cache_mode, all of these are optimizable-side tools. Looking at the plan to debug a slow DDL or DCL is pointless because there is no plan. By the same logic, an ORM or migration tool that wraps ALTER TABLE in a prepared statement assuming "the plan will be cached anyway" has the wrong mental model. Utility commands have no plan; every call grabs and releases catalog locks while running directly. Slow utility is almost always lock contention or I/O cost, not a plan choice issue, so the diagnostic path is to set log_min_duration_statement to capture timings, watch lock waits in pg_stat_activity, and look at wait_events to see where the command is stuck.

Second, audit and security requirements split into two camps and attach to different mechanisms. Tracking "who changed which schema and when" lives on the utility side. pgaudit captures ALTER/CREATE/DROP/GRANT into an audit log because it sits on ProcessUtility_hook. Row-level access control like "this user can only see a subset of rows in this table" lives on the optimizable side. RLS (Row-Level Security) runs in the rewriter, automatically attaching extra WHERE conditions to SELECT/UPDATE/DELETE. The two requirements get bundled under the same security umbrella, but they hook into completely different stages of the pipeline. RLS cannot stop a schema change, and ProcessUtility_hook cannot filter rows. When a compliance requirement comes in, the first task is to classify it as schema-level tracking versus row-level access control. Only then do the candidate tools fall into place, and you almost always need both mechanisms together to leave no gaps.