How the Postgres Query Optimizer Works

Explaining the Postgres Query Optimizer
BRUCE MOMJIAN
January, 2015
The optimizer is the "brain" of the database, interpreting SQL
queries and determining the fastest method of execution. This
talk uses the EXPLAIN command to show how the optimizer
interprets queries and determines optimal execution.
Creative Commons Attribution License http://momjian.us/presentations
1 / 61

PostgreSQL the database…
◮ Open Source Object Relational DBMS since 1996
◮ Distributed under the PostgreSQL License
◮ Similar technical heritage as Oracle, SQL Server & DB2
◮ However, a strong adherence to standards (ANSI-SQL 2008)
◮ Highly extensible and adaptable design
◮ Languages, indexing, data types, etc.
◮ E.g. PostGIS, JSONB, SQL/MED
◮ Extensive use throughout the world for applications and
organizations of all types
◮ Bundled into Red Hat Enterprise Linux, Ubuntu, CentOS
and Amazon Linux
Explaining the Postgres Query Optimizer 2 / 61

PostgreSQL the community…
◮ Independent community led by a Core Team of six
◮ Large, active and vibrant community
◮ www.postgresql.org
◮ Downloads, Mailing lists, Documentation
◮ Sponsors sampler:
◮ Google, Red Hat, VMWare, Skype, Salesforce, HP and
EnterpriseDB
◮ http://www.postgresql.org/community/

EnterpriseDB the company…
◮ The worldwide leader of Postgres based products and
services founded in 2004
◮ Customers include 50 of the Fortune 500 and 98 of the
Forbes Global 2000
◮ Enterprise offerings:
◮ PostgreSQL Support, Services and Training
◮ Postgres Plus Advanced Server with Oracle Compatibility
◮ Tools for Monitoring, Replication, HA, Backup & Recovery
Community
◮ Citizenship
◮ Contributor of key features: Materialized Views, JSON, &
more
◮ Nine community members on staff

EnterpriseDB the company…

Postgres Query Execution
User
Terminal
Code
Database
Server
Application
Queries
Results
PostgreSQL
Libpq

utility
Plan
Optimal Path
Query
Postmaster
Postgres Postgres
Libpq
Main
Generate Plan
Traffic Cop
Generate Paths
Execute Plan
e.g. CREATE TABLE, COPY
SELECT, INSERT, UPDATE, DELETE
Rewrite Query
Parse Statement
Utility
Command
Storage ManagersCatalogUtilities
Access Methods Nodes / Lists

utility
Plan
Optimal Path
Query
Generate Plan
Traffic Cop
Generate Paths
Execute Plan
e.g. CREATE TABLE, COPY
SELECT, INSERT, UPDATE, DELETE
Rewrite Query
Parse Statement
Utility
Command

The Optimizer Is the Brain
http://www.wsmanaging.com/

What Decisions Does the Optimizer Have to Make?
◮ Scan Method
◮ Join Method
◮ Join Order

Which Scan Method?
◮ Sequential Scan
◮ Bitmap Index Scan
◮ Index Scan

A Simple Example Using pg_class.relname
SELECT relname
FROM pg_class
ORDER BY 1
LIMIT 8;
relname
-----------------------------------
_pg_foreign_data_wrappers
_pg_foreign_servers
_pg_user_mappings
administrable_role_authorizations
applicable_roles
attributes
check_constraint_routine_usage
check_constraints
(8 rows)

Let’s Use Just the First Letter of pg_class.relname
SELECT substring(relname, 1, 1)
FROM pg_class
ORDER BY 1
LIMIT 8;
substring
-----------
_
_
_
a
a
a
c
c
(8 rows)

Create a Temporary Table with an Index
CREATE TEMPORARY TABLE sample (letter, junk) AS
SELECT substring(relname, 1, 1), repeat(’x’, 250)
FROM pg_class
ORDER BY random(); -- add rows in random order
SELECT 253
CREATE INDEX i_sample on sample (letter);
CREATE INDEX
All the queries used in this presentation are available at
http://momjian.us/main/writings/pgsql/optimizer.sql.

Create an EXPLAIN Function
CREATE OR REPLACE FUNCTION lookup_letter(text) RETURNS SETOF text AS $$
BEGIN
RETURN QUERY EXECUTE ’
EXPLAIN SELECT letter
FROM sample
WHERE letter = ’’’ || $1 || ’’’’;
END
$$ LANGUAGE plpgsql;
CREATE FUNCTION

What is the Distribution of the sample Table?
WITH letters (letter, count) AS (
SELECT letter, COUNT(*)
FROM sample
GROUP BY 1
)
SELECT letter, count, (count * 100.0 / (SUM(count) OVER ()))::numeric(4,1) AS "%"
FROM letters
ORDER BY 2 DESC;

What is the Distribution of the sample Table?
letter | count | %
--------+-------+------
p | 199 | 78.7
s | 9 | 3.6
c | 8 | 3.2
r | 7 | 2.8
t | 5 | 2.0
v | 4 | 1.6
f | 4 | 1.6
d | 4 | 1.6
u | 3 | 1.2
a | 3 | 1.2
_ | 3 | 1.2
e | 2 | 0.8
i | 1 | 0.4
k | 1 | 0.4
(14 rows)

Is the Distribution Important?
FROM sample
WHERE letter = ’p’;
QUERY PLAN
------------------------------------------------------------------------
Index Scan using i_sample on sample (cost=0.00..8.27 rows=1 width=32)
Index Cond: (letter = ’p’::text)
(2 rows)

FROM sample
WHERE letter = ’d’;
QUERY PLAN
------------------------------------------------------------------------
Index Cond: (letter = ’d’::text)
(2 rows)

FROM sample
WHERE letter = ’k’;
QUERY PLAN
------------------------------------------------------------------------
Index Cond: (letter = ’k’::text)
(2 rows)

Running ANALYZE Causes
a Sequential Scan for a Common Value
ANALYZE sample;
ANALYZE
FROM sample
WHERE letter = ’p’;
QUERY PLAN
---------------------------------------------------------
Seq Scan on sample (cost=0.00..13.16 rows=199 width=2)
Filter: (letter = ’p’::text)
(2 rows)
Autovacuum cannot ANALYZE (or VACUUM) temporary tables because
these tables are only visible to the creating session.

Sequential Scan
T
A
D
A
T
A
D
A
T
A
D
A
T
A
D
A
T
A
D
A
T
A
D
A
T
A
D
A
T
A
D
A
T
A
D
8K
Heap
A
A
D
T
A
T
A
D
A
T
A
D
A

A Less Common Value Causes a Bitmap Index Scan
FROM sample
WHERE letter = ’d’;
QUERY PLAN
-----------------------------------------------------------------------
Bitmap Heap Scan on sample (cost=4.28..12.74 rows=4 width=2)
Recheck Cond: (letter = ’d’::text)
-> Bitmap Index Scan on i_sample (cost=0.00..4.28 rows=4 width=0)
Index Cond: (letter = ’d’::text)
(4 rows)

Bitmap Index Scan
=&
Combined
’A’ AND ’NS’
1
0
1
0
TableIndex 1
col1 = ’A’
Index 2
1
0
0
col2 = ’NS’
1 0
1
0
0
Index

An Even Rarer Value Causes an Index Scan
FROM sample
WHERE letter = ’k’;
QUERY PLAN
-----------------------------------------------------------------------
Index Cond: (letter = ’k’::text)
(2 rows)

Index Scan
A
D
A
T
A
D
A
T
A
D
A
T
A
D
A
T
A
D
A
T
A
D
A
T
A
D
< >=Key
< >=Key
Index
Heap
< >=Key
A
T
A
D
A
T
A
D
A
T
A
D
A
T
A
D
A
T
A
D
A
T

Let’s Look at All Values and their Effects
WITH letter (letter, count) AS (
FROM sample
GROUP BY 1
)
SELECT letter AS l, count, lookup_letter(letter)
FROM letter
ORDER BY 2 DESC;
l | count | lookup_letter
---+-------+-----------------------------------------------------------------------
p | 199 | Seq Scan on sample (cost=0.00..13.16 rows=199 width=2)
p | 199 | Filter: (letter = ’p’::text)
s | 9 | Seq Scan on sample (cost=0.00..13.16 rows=9 width=2)
s | 9 | Filter: (letter = ’s’::text)
c | 8 | Seq Scan on sample (cost=0.00..13.16 rows=8 width=2)
c | 8 | Filter: (letter = ’c’::text)
r | 7 | Seq Scan on sample (cost=0.00..13.16 rows=7 width=2)
r | 7 | Filter: (letter = ’r’::text)
…

OK, Just the First Lines
FROM sample
GROUP BY 1
)
SELECT letter AS l, count,
(SELECT *
FROM lookup_letter(letter) AS l2
LIMIT 1) AS lookup_letter
FROM letter
ORDER BY 2 DESC;

Just the First EXPLAIN Lines
---+-------+-----------------------------------------------------------------------
t | 5 | Bitmap Heap Scan on sample (cost=4.29..12.76 rows=5 width=2)
f | 4 | Bitmap Heap Scan on sample (cost=4.28..12.74 rows=4 width=2)
v | 4 | Bitmap Heap Scan on sample (cost=4.28..12.74 rows=4 width=2)
d | 4 | Bitmap Heap Scan on sample (cost=4.28..12.74 rows=4 width=2)
a | 3 | Bitmap Heap Scan on sample (cost=4.27..11.38 rows=3 width=2)
_ | 3 | Bitmap Heap Scan on sample (cost=4.27..11.38 rows=3 width=2)
u | 3 | Bitmap Heap Scan on sample (cost=4.27..11.38 rows=3 width=2)
e | 2 | Index Scan using i_sample on sample (cost=0.00..8.27 rows=1 width=2)
i | 1 | Index Scan using i_sample on sample (cost=0.00..8.27 rows=1 width=2)
k | 1 | Index Scan using i_sample on sample (cost=0.00..8.27 rows=1 width=2)
(14 rows)

We Can Force an Index Scan
SET enable_seqscan = false;
SET enable_bitmapscan = false;
FROM sample
GROUP BY 1
)
SELECT letter AS l, count,
(SELECT *
FROM lookup_letter(letter) AS l2
LIMIT 1) AS lookup_letter
FROM letter
ORDER BY 2 DESC;

Notice the High Cost for Common Values
---+-------+-----------------------------------------------------------------------
p | 199 | Index Scan using i_sample on sample (cost=0.00..39.33 rows=199 width=
s | 9 | Index Scan using i_sample on sample (cost=0.00..22.14 rows=9 width=2)
c | 8 | Index Scan using i_sample on sample (cost=0.00..19.84 rows=8 width=2)
r | 7 | Index Scan using i_sample on sample (cost=0.00..19.82 rows=7 width=2)
t | 5 | Index Scan using i_sample on sample (cost=0.00..15.21 rows=5 width=2)
d | 4 | Index Scan using i_sample on sample (cost=0.00..15.19 rows=4 width=2)
v | 4 | Index Scan using i_sample on sample (cost=0.00..15.19 rows=4 width=2)
f | 4 | Index Scan using i_sample on sample (cost=0.00..15.19 rows=4 width=2)
_ | 3 | Index Scan using i_sample on sample (cost=0.00..12.88 rows=3 width=2)
a | 3 | Index Scan using i_sample on sample (cost=0.00..12.88 rows=3 width=2)
u | 3 | Index Scan using i_sample on sample (cost=0.00..12.88 rows=3 width=2)
(14 rows)
RESET ALL;
RESET

This Was the Optimizer’s Preference
---+-------+-----------------------------------------------------------------------
t | 5 | Bitmap Heap Scan on sample (cost=4.29..12.76 rows=5 width=2)
f | 4 | Bitmap Heap Scan on sample (cost=4.28..12.74 rows=4 width=2)
v | 4 | Bitmap Heap Scan on sample (cost=4.28..12.74 rows=4 width=2)
d | 4 | Bitmap Heap Scan on sample (cost=4.28..12.74 rows=4 width=2)
a | 3 | Bitmap Heap Scan on sample (cost=4.27..11.38 rows=3 width=2)
_ | 3 | Bitmap Heap Scan on sample (cost=4.27..11.38 rows=3 width=2)
u | 3 | Bitmap Heap Scan on sample (cost=4.27..11.38 rows=3 width=2)
(14 rows)

Which Join Method?
◮ Nested Loop
◮ With Inner Sequential Scan
◮ With Inner Index Scan
◮ Hash Join
◮ Merge Join

What Is in pg_proc.oid?
SELECT oid
FROM pg_proc
ORDER BY 1
LIMIT 8;
oid
-----
31
33
34
35
38
39
40
41
(8 rows)

Create Temporary Tables
from pg_proc and pg_class
CREATE TEMPORARY TABLE sample1 (id, junk) AS
SELECT oid, repeat(’x’, 250)
FROM pg_proc
SELECT 2256
CREATE TEMPORARY TABLE sample2 (id, junk) AS
SELECT oid, repeat(’x’, 250)
FROM pg_class
SELECT 260
These tables have no indexes and no optimizer statistics.

Join the Two Tables
with a Tight Restriction
EXPLAIN SELECT sample2.junk
FROM sample1 JOIN sample2 ON (sample1.id = sample2.id)
WHERE sample1.id = 33;
QUERY PLAN
---------------------------------------------------------------------
Nested Loop (cost=0.00..234.68 rows=300 width=32)
-> Seq Scan on sample1 (cost=0.00..205.54 rows=50 width=4)
Filter: (id = 33::oid)
-> Materialize (cost=0.00..25.41 rows=6 width=36)
Filter: (id = 33::oid)
(6 rows)

Nested Loop Join
with Inner Sequential Scan
aag
aar
aay aag
aas
aar
aaa
aay
aai
aag
No Setup Required
aai
Used For Small Tables
Outer Inner

Pseudocode for Nested Loop Join
with Inner Sequential Scan
for (i = 0; i < length(outer); i++)
for (j = 0; j < length(inner); j++)
if (outer[i] == inner[j])
output(outer[i], inner[j]);

Join the Two Tables with a Looser Restriction
WHERE sample2.id > 33;
QUERY PLAN
----------------------------------------------------------------------
Hash Join (cost=30.50..950.88 rows=20424 width=32)
Hash Cond: (sample1.id = sample2.id)
-> Hash (cost=25.38..25.38 rows=410 width=4)
Filter: (id > 33::oid)
(6 rows)

Hash Join
Hashed
Must fit in Main Memory
aak
aar
aak
aay aaraam
aao aaw
aay
aag
aas
Outer Inner

Pseudocode for Hash Join
for (j = 0; j < length(inner); j++)
hash_key = hash(inner[j]);
append(hash_store[hash_key], inner[j]);
hash_key = hash(outer[i]);
for (j = 0; j < length(hash_store[hash_key]); j++)
if (outer[i] == hash_store[hash_key][j])

Join the Two Tables with No Restriction
FROM sample1 JOIN sample2 ON (sample1.id = sample2.id);
QUERY PLAN
-------------------------------------------------------------------------
Merge Join (cost=927.72..1852.95 rows=61272 width=32)
Merge Cond: (sample2.id = sample1.id)
-> Sort (cost=85.43..88.50 rows=1230 width=4)
Sort Key: sample2.id
(8 rows)

Merge Join
Sorted
Sorted
Ideal for Large Tables
An Index Can Be Used to Eliminate the Sort
aaa
aab
aac
aad
aaa
aab
aab
aaf
aaf
aac
aae
Outer Inner

Pseudocode for Merge Join
sort(outer);
sort(inner);
i = 0;
j = 0;
save_j = 0;
while (i < length(outer))
if (outer[i] == inner[j])
if (outer[i] <= inner[j] && j < length(inner))
j++;
if (outer[i] < inner[j])
save_j = j;
else
i++;
j = save_j;

Order of Joined Relations Is Insigniﬁcant
QUERY PLAN
------------------------------------------------------------------------
Merge Join (cost=927.72..1852.95 rows=61272 width=32)
Merge Cond: (sample2.id = sample1.id)
(8 rows)
The most restrictive relation, e.g. sample2, is always on the outer side of
merge joins. All previous merge joins also had sample2 in outer position.

Add Optimizer Statistics
ANALYZE sample1;
ANALYZE sample2;

This Was a Merge Join without Optimizer Statistics
QUERY PLAN
------------------------------------------------------------------------
(5 rows)

Outer Joins Can Affect Optimizer Join Usage
FROM sample1 RIGHT OUTER JOIN sample2 ON (sample1.id = sample2.id);
QUERY PLAN
--------------------------------------------------------------------------
Hash Left Join (cost=131.76..148.26 rows=260 width=254)
(5 rows)
Use of hashes for outer joins was added in Postgres 9.1.

Cross Joins Are Nested Loop Joins
without Join Restriction
FROM sample1 CROSS JOIN sample2;
QUERY PLAN
----------------------------------------------------------------------
-> Materialize (cost=0.00..13.90 rows=260 width=0)
(4 rows)

Create Indexes
CREATE INDEX i_sample1 on sample1 (id);
CREATE INDEX i_sample2 on sample2 (id);

Nested Loop with Inner Index Scan Now Possible
WHERE sample1.id = 33;
QUERY PLAN
---------------------------------------------------------------------------------
-> Index Scan using i_sample1 on sample1 (cost=0.00..8.27 rows=1 width=4)
Index Cond: (id = 33::oid)
Index Cond: (sample2.id = 33::oid)
(5 rows)

Nested Loop Join with Inner Index Scan
aag
aar
aai
aay aag
aas
aar
aaa
aay
aai
aag
No Setup Required
Index Lookup
Index Must Already Exist
Outer Inner

Pseudocode for Nested Loop Join
with Inner Index Scan
index_entry = get_first_match(outer[j])
while (index_entry)
output(outer[i], inner[index_entry]);
index_entry = get_next_match(index_entry);

Query Restrictions Affect Join Usage
WHERE sample2.junk ˜ ’^aaa’;
QUERY PLAN
-------------------------------------------------------------------------------
Filter: (junk ˜ ’^aaa’::text)
Index Cond: (sample1.id = sample2.id)
(5 rows)
No junk rows begin with ’aaa’.

All ’junk’ Columns Begin with ’xxx’
WHERE sample2.junk ˜ ’^xxx’;
QUERY PLAN
------------------------------------------------------------------------
Filter: (junk ˜ ’^xxx’::text)
(6 rows)
Hash join was chosen because many more rows are expected. The
smaller table, e.g. sample2, is always hashed.

Without LIMIT, Hash Is Used
for this Unrestricted Join
QUERY PLAN
------------------------------------------------------------------------
(5 rows)

LIMIT Can Affect Join Usage
EXPLAIN SELECT sample2.id, sample2.junk
ORDER BY 1
LIMIT 1;
QUERY PLAN
------------------------------------------------------------------------------------------
Limit (cost=0.00..1.83 rows=1 width=258)
-> Nested Loop (cost=0.00..477.02 rows=260 width=258)
(5 rows)

LIMIT 10
ORDER BY 1
LIMIT 10;
QUERY PLAN
------------------------------------------------------------------------------------------
-> Nested Loop (cost=0.00..477.02 rows=260 width=258)
(5 rows)

LIMIT 100 Switches to Hash Join
ORDER BY 1
LIMIT 100;
QUERY PLAN
------------------------------------------------------------------------------------
-> Hash Join (cost=15.85..130.47 rows=260 width=258)
(8 rows)

Additional Resources…
◮ Postgres Downloads:
◮ www.enterprisedb.com/downloads
◮ Product and Services information:
◮ info@enterprisedb.com

Conclusion
http://momjian.us/presentations http://www.vivapixel.com/photo/14252

How the Postgres Query Optimizer Works

Recommended

More Related Content

What's hot (20)

Viewers also liked (15)

Similar to How the Postgres Query Optimizer Works (20)

More from EDB (20)

Recently uploaded (20)

How the Postgres Query Optimizer Works