Re: Remedial C: Does an ltree GiST index *ever* set recheck to true?
От | Tom Lane |
---|---|
Тема | Re: Remedial C: Does an ltree GiST index *ever* set recheck to true? |
Дата | |
Msg-id | 330807.1724984291@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Remedial C: Does an ltree GiST index *ever* set recheck to true? (Morris de Oryx <morrisdeoryx@gmail.com>) |
Ответы |
Re: Remedial C: Does an ltree GiST index *ever* set recheck to true?
|
Список | pgsql-general |
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
В списке pgsql-general по дате отправления: