Search Postgresql Archives

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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



As always, thanks very much for the confirmation.

On Fri, Aug 30, 2024 at 12:18 PM Tom Lane <tgl@xxxxxxxxxxxxx> wrote:
Morris de Oryx <morrisdeoryx@xxxxxxxxx> 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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]

  Powered by Linux