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

1 Answer 1


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.

  • You're a genius. Yes, the tool I was using was establishing a new connection on each query. Thank you so much that was driving me crazy.
    – Nick
    Commented Jul 16, 2018 at 5:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.