
The very first line (the summary line for the topmost node) has the estimated total execution cost for the plan it is this number that the planner seeks to minimize. Additional lines might appear, indented from the node's summary line, to show additional properties of the node.
#Postgres query plan plus#
The output of EXPLAIN has one line for each node in the plan tree, showing the basic node type plus the cost estimates that the planner made for the execution of that plan node. Again, there is usually more than one possible way to do these operations, so different node types can appear here too. If the query requires joining, aggregation, sorting, or other operations on the raw rows, then there will be additional nodes above the scan nodes to perform these operations. There are also non-table row sources, such as VALUES clauses and set-returning functions in FROM, which have their own scan node types. There are different types of scan nodes for different table access methods: sequential scans, index scans, and bitmap index scans.

Nodes at the bottom level of the tree are scan nodes: they return raw rows from a table. The structure of a query plan is a tree of plan nodes.

If you want to feed EXPLAIN's output to a program for further analysis, you should use one of its machine-readable output formats (XML, JSON, or YAML) instead. The examples use EXPLAIN's default “ text” output format, which is compact and convenient for humans to read. You should be able to get similar results if you try the examples yourself, but your estimated costs and row counts might vary slightly because ANALYZE's statistics are random samples rather than exact, and because costs are inherently somewhat platform-dependent. Plan-reading is an art that requires some experience to master, but this section attempts to cover the basics.Įxamples in this section are drawn from the regression test database after doing a VACUUM ANALYZE, using 9.3 development sources. You can use the EXPLAIN command to see what query plan the planner creates for any query. Choosing the right plan to match the query structure and the properties of the data is absolutely critical for good performance, so the system includes a complex planner that tries to choose good plans. PostgreSQL devises a query plan for each query it receives.
