From: Tom Lane <tgl@sss.pgh.pa.us>
To: Morris de Oryx <morrisdeoryx@gmail.com>
cc: pgsql-general <pgsql-general@postgresql.org>
Subject: Re: Remedial C: Does an ltree GiST index *ever* set recheck to true?
In-reply-to: <CAKqnccgejE8E5xheLMd+pDtQ+nXiZHoGhf6yN3FsJ2_rtGzx2g@mail.gmail.com>
References: <CAKqnccgejE8E5xheLMd+pDtQ+nXiZHoGhf6yN3FsJ2_rtGzx2g@mail.gmail.com>
Comments: In-reply-to Morris de Oryx <morrisdeoryx@gmail.com>
	message dated "Fri, 30 Aug 2024 11:51:51 +1000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <330806.1724984291.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Thu, 29 Aug 2024 22:18:11 -0400
Message-ID: <330807.1724984291@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/330807.1724984291%40sss.pgh.pa.us>
Precedence: bulk

Morris de Oryx <morrisdeoryx@gmail.com> writes:
> From what I've seen in the wild, and can sort out from the source, I thi=
nk
> that ltree does *not* need to load rows from heap.

The comment in ltree_consistent is pretty definitive:

	/* All cases served by this function are exact */
	*recheck =3D false;

> I wonder because an ltree GiST index is "lossy" and this behavior is mor=
e
> like a lossless strategy. I think that's either because I've misundersto=
od
> what "lossy" means in this case, or it's because ltree GiST index *pages=
 *are
> based on a signature (lossy), while ltree GiST index *leaf entries* cont=
ain
> the full tree/path (lossless.)

Yeah, the code is not terribly well commented but this bit in ltree.h
appears to be saying that leaf entries contain the original ltree:

 * type of index key for ltree. Tree are combined B-Tree and R-Tree
 * Storage:
 *    Leaf pages
 *        (len)(flag)(ltree)
 *    Non-Leaf
 *                 (len)(flag)(sign)(left_ltree)(right_ltree)
 *        ALLTRUE: (len)(flag)(left_ltree)(right_ltree)

and that seems consistent with the fact that ltree_consistent
does different things at leaf and non-leaf levels.

			regards, tom lane