Thanks for your valuable input, Michael! > On 29 Nov 2024, at 09:42, Michael Paquier <mich...@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 IndexScan performance. Best regards, Andrey Borodin.
