Re: nbtree: opt-in leaf key prefix compression

On Wed, 04 Nov 2026 14:31:45 +0000, Greg Burd <greg(at)burd(dot)me> wrote:
>
> On Tuesday, November 3rd, 2026 at 4:48 PM, Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
>
> > It seems likely that a design such as yours, which omits column-level
> > compression, will never incorporate it later on once committed. Why do
> > you think that's the best trade-off? I personally tend to doubt that
> > it is, but I've given it little thought so who knows?
>
> Column-level compression is a great technique, and I'd like to see that
> happen too. The time line for that is much longer primarily due to the
> many ways that table/index/executor all implicitly agree on one shape
> and one behavior defined by heap. If we can more cleanly separate and
> define the boundaries between those three then we could potentially see
> that in core at some point, but I'll bet that takes a few years to sort
> out. In the mean time, let's compress some key prefixes and save some
> bytes.
>
> I think these two are not in competition, they are orthogonal and both
> is the answer but the easier of the two in today's code base is the
> prefix compression.

Quick follow-up...

I may have misunderstood "column-level" to mean "columnar" and if that's
the case I apologize. I think you are talking more about key prefix
compression across multiple columns that together form the btree key,
and if that's the case then yes I agree that's something required of a
solution. I'd been side-stepping this just for simplicity sake but I'll
think about it a bit and see if I can bring that into the design.

best.

-greg