Was there a reason to exceed 100-500 partitions in real life that pushed
you to do this test? Is there some issue you see when using 100 partitions
that is solved or reduced in severity by increasing to 1200 or 6000
partitions?
On Tue, 13 Aug 2019 at 08:03, Piotr Włodarczyk
wrote:
> PostgreSQL11.5:
>
> select on main partition (public.book): planner: 60ms, execution: 5ms
> select on partitioned table (public.book_1-1000): planner: 2.7 ms, execution:
> 2,4 ms
>
> PostgreSQL 12B3:
>
> select on main partition (public.book
Thanks for clarifying your position and sharing the results you have seen.
That is impressive indeed.
It seems likely that waiting for v12 is needed since feature are not back
patched. Perhaps one of the contributors will confirm, but that is my
expectation.
Queries against tables with a lot of partitions (> 1000) start to incur
an increasing planning time duration even with the current version,
V11. V12 purportedly has fixed this problem, allowing thousands of
partitioned tables without a heavy planning cost. Can't seem to find
the threads on th
"It is also important to consider the overhead of partitioning during query
planning and execution. The query planner is generally able to handle
partition hierarchies with *up to a few hundred partitions fairly well*,
provided that typical queries allow the query planner to prune all but a
small n
