| From: | Morris de Oryx <morrisdeoryx(at)gmail(dot)com> |
|---|---|
| To: | pgsql-general <pgsql-general(at)postgresql(dot)org> |
| Subject: | Remedial C: Does an ltree GiST index *ever* set recheck to true? |
| Date: | 2024-08-30 01:51:51 |
| Message-ID: | CAKqnccgejE8E5xheLMd+pDtQ+nXiZHoGhf6yN3FsJ2_rtGzx2g@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2024-08-30 02:18:11 | Re: Remedial C: Does an ltree GiST index *ever* set recheck to true? |
| Previous Message | David Rowley | 2024-08-30 01:24:17 | Re: Analytic Function Bug |