Why is my planning time consistently slower than execution time?

On small tables with 5,000 rows I get:

SELECT category_id FROM widgets WHERE category_id = 1;
Index Only Scan using widgets_category_id on widgets  (cost=0.28..5.20 rows=26 width=8) (actual time=0.083..0.160 rows=70 loops=1)
Index Cond: (category_id = 1)
Heap Fetches: 7
Planning time: 2.758 ms
Execution time: 0.213 ms

and on large tables with 100m rows I get:

SELECT customer_id FROM orders WHERE customer_id = 1;
Index Only Scan using orders_customer_id on orders  (cost=0.58..1372.32 rows=65243 width=8) (actual time=0.155..0.402 rows=158 loops=1)
Index Cond: (customer_id = 1)
Heap Fetches: 109
Planning time: 16.019 ms
Execution time: 0.493 ms

This seems to be a consistent theme when running a bunch of different queries on different tables.

I'm using version 10.4, here are some settings:

shared_buffers is 64GB (25% of total RAM)
default_statistics_target = 100
constraint_exclusion = partition

The only time I see planning times that slow for such simple queries is the first time a table is used in a given connection. Then it has to read the metadata about the table and its indexes and statistics, perhaps from disk.

Is that is actually a problem? If so, you could use a connection pooler so you re-use the connections with the metadata already in memory.

StackExchange Database Administrators Q#212259, answer score: 2