PostgreSQL 11 added support for query plans that do partitionwise
aggregation on partitioned tables. Such query plans push down
aggregates to individual partitions (either fully or partially) for
similar or better performance than regular plans due to, among other
things, improved locking.
The changes in this commit adds the corresponding partitionwise
aggregation functionality for hypertables. To enable this
functionality on hypertables, we add partitioning metadata at the
planning stage to make the regular PostgreSQL planner believe it is
planning a partitioned table. Alternatively, we could have added the
corresponding planner paths in our own code, e.g., in the
create_upper_paths_hook, but this would require copying or
re-implementing a large amount of PostgreSQL planning code.
Note that partitionwise aggregation will only work with PostgreSQL 11.
As a side effect of making hypertables look like partitioned tables
during planning, some append plans will differ because the planner
removes any Result projection nodes from such plans, knowing it can
push projections down to the partitions instead. This also affects a
number of query-related tests, so these have been split into
version-specific tests.
Since the parent table of a hypertable cannot contain
any rows including it in the plan is not necessary. PostgreSQL might
also not have good statistics for the main table as autoanalyze is
triggered by inserts which never happen to the main table, leading to
worse plans.
This patch adds a new guc enable_constraint_exclusion to disable
planner constraint exclusion. Constraint exclusion will not work with
cursors and WHERE CURRENT OF so the new guc will allow you to disable
that feature.
This patch also fixes constraint exclusion for JOINs and sort
optimization for queries with chunks_in.
The sort transform optimization to enable index usage are only
safe transformations when the modified PathKey is either the last
member of pathkeys or the only member.
