Re: Remedial C: Does an ltree GiST index *ever* set recheck to true?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Morris de Oryx <morrisdeoryx(at)gmail(dot)com>
Cc: pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: Remedial C: Does an ltree GiST index *ever* set recheck to true?
Date: 2024-08-30 02:18:11
Message-ID: 330807.1724984291@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Morris de Oryx <morrisdeoryx(at)gmail(dot)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message James Brown 2024-08-30 02:49:27 optimizing a join against a windowed function
Previous Message Morris de Oryx 2024-08-30 01:51:51 Remedial C: Does an ltree GiST index *ever* set recheck to true?