Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51\))
Subject: Re: [PATCH] Add sortsupport for range types and btree_gist
From: "Andrey M. Borodin" <x4mmm@yandex-team.ru>
In-Reply-To: <Z0lGG9B1gSJXEwzh@paquier.xyz>
Date: Fri, 29 Nov 2024 14:41:56 +0500
Cc: Bernd Helmle <mailings@oopsware.de>,
 jian he <jian.universality@gmail.com>,
 PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <52D98799-54D0-4902-A65B-ED3443C7D58C@yandex-team.ru>
References: <a380cfd805c37c2aa70b1083d45820e1a7cbe759.camel@oopsware.de>
 <7C9400DF-66FE-4308-BAD8-92FE3D0E55C6@yandex-team.ru>
 <0d9fbd59de15e2fc987a850c3d1f8a79a6ede825.camel@oopsware.de>
 <19c62e62c79b727d2c9a82eaeecfea5017001099.camel@oopsware.de>
 <4BADF8DD-A4D3-43AA-AA08-037F6FFA40BC@yandex-team.ru>
 <61128550659807032dd29c8c8a71674c818cbbb6.camel@oopsware.de>
 <7095B5FA-FADB-4524-B858-ECD14998710B@yandex-team.ru>
 <0176b173adfcff250543fe0aee2ef6137bd71953.camel@oopsware.de>
 <bcdf583f38e7991a374c00ad77bb3adde24d8143.camel@oopsware.de>
 <F6394698-D6BD-469A-BEC4-2D23D348A324@yandex-team.ru>
 <Z0lGG9B1gSJXEwzh@paquier.xyz>
To: Michael Paquier <michael@paquier.xyz>
Archived-At: <https://www.postgresql.org/message-id/52D98799-54D0-4902-A65B-ED3443C7D58C%40yandex-team.ru>
Precedence: bulk

Thanks for your valuable input, Michael!

> On 29 Nov 2024, at 09:42, Michael Paquier <michael@paquier.xyz> wrote:
>=20
> 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=E2=80=99s 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=E2=80=99s 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.