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.
We do not need (nor can use) statistics for hash partitions, but those can
exist anywhere in the partitioning tree. So just forbidding hypopg_analyze()
if the first level is partitioned by hash was wrong.
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.
