MIME-Version: 1.0
From: Morris de Oryx <morrisdeoryx@gmail.com>
Date: Fri, 30 Aug 2024 11:51:51 +1000
Message-ID: <CAKqnccgejE8E5xheLMd+pDtQ+nXiZHoGhf6yN3FsJ2_rtGzx2g@mail.gmail.com>
Subject: Remedial C: Does an ltree GiST index *ever* set recheck to true?
To: pgsql-general <pgsql-general@postgresql.org>
Content-Type: multipart/alternative; boundary="0000000000004cc5e10620dcd643"
Archived-At: <https://www.postgresql.org/message-id/CAKqnccgejE8E5xheLMd%2BpDtQ%2BnXiZHoGhf6yN3FsJ2_rtGzx2g%40mail.gmail.com>
Precedence: bulk

--0000000000004cc5e10620dcd643
Content-Type: text/plain; charset="UTF-8"

I'm trying to determine if an ltree GiST index search *ever *needs to load
a row out of heap for a recheck, of if the index entry itself includes
enough information for a definitive answer. I believe that this is
controlled by the recheck flag in the consistency function.

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.

https://github.com/postgres/postgres/blob/master/contrib/ltree/ltree_gist.c

I wonder because an ltree GiST index is "lossy" and this behavior is more
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 *pages *are
based on a signature (lossy), while ltree GiST index *leaf entries* contain
the full tree/path (lossless.)

Can anyone confirm or deny for me? I'd be grateful for the certainty.

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

<div dir=3D"ltr">I&#39;m trying to determine if an <font face=3D"monospace"=
>ltree</font>=C2=A0GiST index search <i>ever </i>needs to load a row out of=
 heap for a recheck, of if the index entry itself includes enough informati=
on for a definitive answer. I believe that this is controlled=C2=A0by the <=
font face=3D"monospace">recheck</font> flag in the consistency=C2=A0functio=
n.<div><br></div><div>From what I&#39;ve seen in the wild, and can sort out=
 from the source, I think that=C2=A0<span style=3D"font-family:monospace">l=
tree</span>=C2=A0does <b>not</b> need to load rows from heap.=C2=A0</div><d=
iv><br></div><div><a href=3D"https://github.com/postgres/postgres/blob/mast=
er/contrib/ltree/ltree_gist.c">https://github.com/postgres/postgres/blob/ma=
ster/contrib/ltree/ltree_gist.c</a><br></div><div><br></div><div>I wonder b=
ecause an=C2=A0<span style=3D"font-family:monospace">ltree=C2=A0</span>GiST=
 index is &quot;lossy&quot; and this=C2=A0behavior is more like a lossless =
strategy. I think that&#39;s either because I&#39;ve misunderstood what &qu=
ot;lossy&quot; means in this case, or it&#39;s because=C2=A0<span style=3D"=
font-family:monospace">ltree=C2=A0</span>GiST index=C2=A0<i>pages </i>are b=
ased on a signature (lossy), while=C2=A0<span style=3D"font-family:monospac=
e">ltree=C2=A0</span>GiST index=C2=A0<i>leaf entries</i><span class=3D"gmai=
l-Apple-converted-space"><i>=C2=A0</i>contain the full=C2=A0tree/path (loss=
less.)</span></div><div><br></div><div>Can anyone confirm or deny for me? I=
&#39;d be grateful for the certainty.</div></div>

--0000000000004cc5e10620dcd643--