public inbox for [email protected]
help / color / mirror / Atom feedRe: Remedial C: Does an ltree GiST index *ever* set recheck to true?
2+ messages / 2 participants
[nested] [flat]
* Re: Remedial C: Does an ltree GiST index *ever* set recheck to true?
@ 2024-08-30 02:18 Tom Lane <[email protected]>
2024-08-30 04:04 ` Re: Remedial C: Does an ltree GiST index *ever* set recheck to true? Morris de Oryx <[email protected]>
0 siblings, 1 reply; 2+ messages in thread
From: Tom Lane @ 2024-08-30 02:18 UTC (permalink / raw)
To: Morris de Oryx <[email protected]>; +Cc: pgsql-general
Morris de Oryx <[email protected]> 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
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: Remedial C: Does an ltree GiST index *ever* set recheck to true?
2024-08-30 02:18 Re: Remedial C: Does an ltree GiST index *ever* set recheck to true? Tom Lane <[email protected]>
@ 2024-08-30 04:04 ` Morris de Oryx <[email protected]>
0 siblings, 0 replies; 2+ messages in thread
From: Morris de Oryx @ 2024-08-30 04:04 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: pgsql-general
As always, thanks very much for the confirmation.
On Fri, Aug 30, 2024 at 12:18 PM Tom Lane <[email protected]> wrote:
> Morris de Oryx <[email protected]> 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
>
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2024-08-30 04:04 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2024-08-30 02:18 Re: Remedial C: Does an ltree GiST index *ever* set recheck to true? Tom Lane <[email protected]>
2024-08-30 04:04 ` Morris de Oryx <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox