We could try to automatically remove such indexes by registering a relcache
callback, but this seems like an unlikely corner case so it doesn't seems worth
spending effort for that, accurately displaying the list of stored hypothetical
indexes should be enough.
Trying to create an hypothetical index with an INCLUDE clause on pg10- will
obviously fail with a syntax error.
Also add regression test for the INCLUDE clause on btree indexes.
To avoid locking on pg_class (required to safely call GetNewOidWithIndex or
similar) and to be usable on a standby node, use the oids unused in the
FirstBootstrapObjectId / FirstNormalObjectId range rather than real oids. For
performance, always start with the biggest oid lesser than FirstNormalObjectId.
This way the loop to find an unused oid will only happens once a single backend
has created more than ~2.5k hypothetical indexes.
For people needing to have thousands of hypothetical indexes at the same time,
we also allow to use the initial implementation that relies on real oids, which
comes with all the limitations mentioned above, with the new
hypopg.use_real_oids GUC.
Upstream postgres will probably soon push some changes that will change the
semantics of explain_get_index_name_hook_type. The returned index name will
automatically be properly quoted if needed, while it was previously the
extension's duty to take care of that, which hypopg failed to do. See
discussion at https://postgr.es/m/flat/16502-57bd1c9f913ed1d1%40postgresql.org
for more details.
To avoid build failure when the change is committed, change brin regression
test to match an hypothetical index name whether is quoted or not, similarly to
how it's done in all other regression tests.
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.
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.
