Remedial C: Does an ltree GiST index *ever* set recheck to true?
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.
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 = false;
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.)
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
As always, thanks very much for the confirmation.
On Fri, Aug 30, 2024 at 12:18 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Show quoted text
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 = false;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'vemisunderstood
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.)
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