MIME-Version: 1.0
References: <CAKqnccgejE8E5xheLMd+pDtQ+nXiZHoGhf6yN3FsJ2_rtGzx2g@mail.gmail.com>
 <330807.1724984291@sss.pgh.pa.us>
In-Reply-To: <330807.1724984291@sss.pgh.pa.us>
From: Morris de Oryx <morrisdeoryx@gmail.com>
Date: Fri, 30 Aug 2024 14:04:18 +1000
Message-ID: <CAKqnccjB0+Otzv7SxCLxWH0g=wqt4JR0osZD4j+dRWrbLhurRA@mail.gmail.com>
Subject: Re: Remedial C: Does an ltree GiST index *ever* set recheck to true?
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-general <pgsql-general@postgresql.org>
Content-Type: multipart/alternative; boundary="0000000000000116af0620deb03e"
Archived-At: <https://www.postgresql.org/message-id/CAKqnccjB0%2BOtzv7SxCLxWH0g%3Dwqt4JR0osZD4j%2BdRWrbLhurRA%40mail.gmail.com>
Precedence: bulk

--0000000000000116af0620deb03e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

As always, thanks very much for the confirmation.

On Fri, Aug 30, 2024 at 12:18=E2=80=AFPM Tom Lane <tgl@sss.pgh.pa.us> wrote=
:

> Morris de Oryx <morrisdeoryx@gmail.com> writes:
> > From what I've seen in the wild, and can sort out from the source, I
> think
> > 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 mo=
re
> > like a lossless strategy. I think that's either because I've
> misunderstood
> > what "lossy" means in this case, or it's because ltree GiST index *page=
s
> *are
> > based on a signature (lossy), while ltree GiST index *leaf entries*
> contain
> > 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
>

--0000000000000116af0620deb03e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">As always, thanks very much for the confirmation.</div><br=
><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, A=
ug 30, 2024 at 12:18=E2=80=AFPM Tom Lane &lt;<a href=3D"mailto:tgl@sss.pgh.=
pa.us">tgl@sss.pgh.pa.us</a>&gt; wrote:<br></div><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left=
-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Morris de=
 Oryx &lt;<a href=3D"mailto:morrisdeoryx@gmail.com" target=3D"_blank">morri=
sdeoryx@gmail.com</a>&gt; writes:<br>
&gt; From what I&#39;ve seen in the wild, and can sort out from the source,=
 I think<br>
&gt; that ltree does *not* need to load rows from heap.<br>
<br>
The comment in ltree_consistent is pretty definitive:<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 /* All cases served by this function are exact =
*/<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 *recheck =3D false;<br>
<br>
&gt; I wonder because an ltree GiST index is &quot;lossy&quot; and this beh=
avior is more<br>
&gt; like a lossless strategy. I think that&#39;s either because I&#39;ve m=
isunderstood<br>
&gt; what &quot;lossy&quot; means in this case, or it&#39;s because ltree G=
iST index *pages *are<br>
&gt; based on a signature (lossy), while ltree GiST index *leaf entries* co=
ntain<br>
&gt; the full tree/path (lossless.)<br>
<br>
Yeah, the code is not terribly well commented but this bit in ltree.h<br>
appears to be saying that leaf entries contain the original ltree:<br>
<br>
=C2=A0* type of index key for ltree. Tree are combined B-Tree and R-Tree<br=
>
=C2=A0* Storage:<br>
=C2=A0*=C2=A0 =C2=A0 Leaf pages<br>
=C2=A0*=C2=A0 =C2=A0 =C2=A0 =C2=A0 (len)(flag)(ltree)<br>
=C2=A0*=C2=A0 =C2=A0 Non-Leaf<br>
=C2=A0*=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(len)(=
flag)(sign)(left_ltree)(right_ltree)<br>
=C2=A0*=C2=A0 =C2=A0 =C2=A0 =C2=A0 ALLTRUE: (len)(flag)(left_ltree)(right_l=
tree)<br>
<br>
and that seems consistent with the fact that ltree_consistent<br>
does different things at leaf and non-leaf levels.<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 regards, tom lane<br>
</blockquote></div>

--0000000000000116af0620deb03e--