public inbox for [email protected]  

help / color / mirror / Atom feed

From: Paul A Jungwirth <[email protected]>
To: Tom Lane <[email protected]>
Cc: [email protected]
Subject: Re: Correct docs about GiST leaf page structure
Date: Sun, 29 Mar 2026 18:35:19 -0700
Message-ID: <CA+renyXv6+tVi2yeQNXRwRkAm=wg89k=orjU8nMRKqWf1q6mtg@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <CA+renyWs5Np+FLSYfL+eu20S4U671A3fQGb-+7e22HLrD1NbYw@mail.gmail.com>
	<[email protected]>

On Sun, Mar 29, 2026 at 12:32 PM Tom Lane <[email protected]> wrote:
>
> Paul A Jungwirth <[email protected]> writes:
> > Our docs for GiST indexes say the compress function is only used for
> > internal pages, not leaf pages, but actually it is used everywhere.
> > Here are two patches to clean things up.
>
> > You can see that we store compressed values with the pageinspect
> > extension. For instance, multiranges are compressed to ranges. Here
> > they are in leaf pages:
>
> Actually I think it's more complicated than that.  A GiST opclass
> can choose whether to compress leaf-key entries, and if it does it
> can use a different representation than it does on internal pages.
> You can see that in action in compress/decompress functions that
> pay attention to the GISTENTRY.leafkey flag, which many do.

Ah, thanks for pointing that out!

> So I'm inclined to propose text more like the attached.  I merged
> your two patches into one (didn't seem all that useful to separate).
> Also, I dropped the adjacent sentence suggesting using the STORAGE
> option.  AFAIK that's pretty useless here: I don't think any GiST
> code pays attention to it.  At least part of the reason is that it's
> inadequate to describe the possibility that leaf and internal datums
> are different.

I think your changes are great. I agree about not needing two commits.
My only hesitation is removing the line about STORAGE. In btree_gist
we do declare the storage of many opclasses. But I'm not sure why. Is
it necessary? Does an opclass gain some advantage from it? Does core
use that information somehow? Especially if leaf keys might or might
not be the same type as internal keys, I'm not sure what value
declaring STORAGE can provide. (It must be for core's sake, not the
opclass's, right?)

Yours,

-- 
Paul              ~{:-)
[email protected]

view thread (6+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: Correct docs about GiST leaf page structure
  In-Reply-To: <CA+renyXv6+tVi2yeQNXRwRkAm=wg89k=orjU8nMRKqWf1q6mtg@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox