PostgreSQL introspection: EXPLAIN returns the planner's strategy tree (sequential scan, hash, hash join, nested loop, filter) with cost-to-first-row, cost-to-last-row, estimated rows, and row width. EXPLAIN ANALYZE actually runs the query, adding real first-row/last-row times, actual row counts, and loop counts. Strategies stream and parallelize — some (like a hash join) must wait for a child strategy (building the hash) to complete, which is what 'cost to first row' captures. For INSERT/UPDATE/DELETE, wrap EXPLAIN ANALYZE in a transaction and roll back (rarely documented). Postgres also keeps query-statistics tables so EXPLAIN can estimate row counts cheaply — Gmail's 'about 300 results' is the same idea. Other options include BUFFERS (how much data was read from disk vs cache; planned default in Postgres 16/17). Planning time is cached on subsequent runs. Costs are unitless 'story points' configurable in postgres.conf to match local hardware characteristics. Rails' built-in `.explain` is limited — accepting more options would make a useful PR.