On Wed, 04 Nov 2026 14:31:45 +0000, Greg Burd <[email protected]> wrote: > > On Tuesday, November 3rd, 2026 at 4:48 PM, Peter Geoghegan <[email protected]> > 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
