And error out instead of returning 0 if that's not the case.
While at it, some iterating over the list of hypothetical indexes once we found
the wanted one.
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.
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.
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.
