Date: Wed, 04 Nov 2026 17:38:49 +0000
To: pg@bowt.ie
From: Greg Burd <greg@burd.me>
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: nbtree: opt-in leaf key prefix compression
Message-ID: <autsJ00Lz3RSy1OB@floki>
In-Reply-To: 
 <7AFniRZ51Rofvz04_p1ypbJYNtVOdgj9Y093sxb6246oFoS4Z6kuwBdFvprrA_rXMA4Wf8CZlvF_PGSErXAaYg5_9yTB3KBcXKzKRPp7hXg=@burd.me>
References: <at-01F1wsXLRH0qo@floki>
 <CAH2-WznyrHYLaROHDtaZfYWn3u6hx7jpzsbpQO_vxk8jDFO8GA@mail.gmail.com>
 <7AFniRZ51Rofvz04_p1ypbJYNtVOdgj9Y093sxb6246oFoS4Z6kuwBdFvprrA_rXMA4Wf8CZlvF_PGSErXAaYg5_9yTB3KBcXKzKRPp7hXg=@burd.me>
Feedback-ID: 2668248:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/autsJ00Lz3RSy1OB%40floki>
Precedence: bulk

On Wed, 04 Nov 2026 14:31:45 +0000, Greg Burd <greg@burd.me> wrote:
>=20
> On Tuesday, November 3rd, 2026 at 4:48 PM, Peter Geoghegan <pg@bowt.ie> w=
rote:
>=20
> > 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?
>=20
> 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.
>=20
> 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