Hypothetical BRIN indexes are broken in some minor versions of pg10, pg11 and
pg12. Detect those versions and warn users with a useful error message
recommending to update their minor versions of postgres.
Also add regression tests to make sure that support BRIN hypothetical indexes
doesn't get broken again.
This unfortunately can't be supported in pg11. Current code is currently
broken, so later commit will add a proper fix to disable runtime partition
pruning on hypothetically partitioned tables.
Previous naive implementation was storing the hypothetical partitions in
a simple List, which would definitely not scale if many hypothetical
partitions are stored.
The partition's children oid are also now maintained in each hypoTable
entry, for performance reason too.
Some minor fixup too while at it.
The underlying C function was already existing, I just forgot to add the
SQL wrapper.
The C function is modified to add an error if the function is called on
a non hypothetically partitioned table instead of silently doing
nothing, and add regression tests.
Register a relcache callback, filter the relid list to keep only the one
corresponding to table that are hypothetically partitioned and
asynchronously process them. We only care about table being dropped, so
in order to detect that we check if the relid we stored still correspond
to a table whose name is the same as the one we recorded when creating
the hypothetical objects.
This will fail on pg10- servers, but since hypothetical partitioning has
some feature not covered by regression tests, a full coverage of hypopg for all
pg versions will be done in other commit(s).
The estimated index size depends on the architecture, so just make
sure the code path is tested, without really caring of what the
estimated size is. Thanks to Christoph Berg for the report.
The estimation (size and cardinality) will probably always be very poor, the
postgres infrastructure get accurate informations by analyzing a real
index. One consequence is that almost only Bitmap Index Scan will be
chosen by the planner.
Some simple and frequent expressions are explicitely handled (for now md5(),
lower() and uppser()), but it only impacts the estimated size, not the
selectivity.
