Thanks for your valuable input, Michael!
> On 29 Nov 2024, at 09:42, Michael Paquier <michael@paquier.xyz> wrote:
>
> As a whole, I'm very dubious about the need for injection points at
> all here. The sortsupport property claimed for this patch tells that
> this results in smaller index sizes, but the tests don't really check
> that: they just make sure that sortsupport routine paths are taken.
> What this should test is not the path taken, but how the new code
> affects the index data generated.
Actually, that’s exactly what we wanted to test: which paths are taken.
Resulting index might be of a very same size in case of B-tree-over-GiST. Resulting index is drastically smaller for
geometry,e.g. PostGIS. But event that’s not main effect: the index is simply build much faster (on par with actual
B-tree).
We need this sort support for btree_gist to be able to use non-geometry datatypes in combination with geometry.
e.g.
CREATE INDEX ON table USING gist(project_id_of_type_int,geometric_column);
Currently, having anything non-geometric in GiST slows down it 10x, because sorting build path is not taken.
In PG15 we put extra effort to make resulting indexes indistinguishable from normally-built. Primarily for the sake of
IndexScanperformance.
Best regards, Andrey Borodin.
