2022-05-31-partition-planning

_posts/2022-05-16-param-query-partition-woes.md

@@ -125,3 +125,11 @@ the graph showing the improved generic plan execution latency after applying the
 
 As expected, the latency no longer degrades, and perhaps more importantly, is indeed lower than with
 forced re-planning on each `EXECUTE`.
+
+Note: With default settings (`plan_cache_mode` = `auto`), Postgres currently chooses a custom plan
+for partitions because a generic plan looks expensive given that it must contain all partitions, so
+the performance one gets by default looks more like the custom line in 2nd graph. Along with the patch
+I mentioned above which improves the execution performance of generic plans for partitions, we will
+also need to fix things such that generic plans don't appear more expensive than custom plans to the
+plan caching logic for it to choose the former.  Till that's also fixed, users will need to use
+`plan_cache_mode` = `force_generic_plan` to have plan caching for partitions.

_posts/2022-05-31-partition-planning.md

@@ -0,0 +1,13 @@
+---
+layout: writing
+title: "Postgres: planning queries with partitioned tables"
+tags: [writing, pg]
+last_updated: 2022-05-31
+---
+
+# Postgres: planning queries with partitioned tables
+
+I have worked on a number of Postgres development projects that involved
+modifying the planner to handle partitioned tables.
+
+...