From: Mike Palmiotto [mailto:mike.palmiotto@crunchydata.com]
> Attached is a patch which attempts to solve a few problems:
>
> 1) Filtering out partitions flexibly based on the results of an external
> function call (supplied by an extension).
> 2) Filtering out partitions from pg_inherits based on the same function
> call.
> 3) Filtering out partitions from a partitioned table BEFORE the partition
> is actually opened on-disk.
What concrete problems would you expect this patch to solve? What kind of extensions do you imagine? I'd like to hear
aboutthe examples. For example, "PostgreSQL 12 will not be able to filter out enough partitions when
planning/executingSELECT ... WHERE ... statement. But an extension like this can extract just one partition early."
Would this help the following issues with PostgreSQL 12?
* UPDATE/DELETE planning takes time in proportion to the number of partitions, even when the actually accessed
partitionduring query execution is only one.
* Making a generic plan takes prohibitably long time (IIRC, about 12 seconds when the number of partitoons is 1,000 or
8,000.)
Regards
Takayuki Tsunakawa
