Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Thu, Aug 6, 2009 at 4:03 PM, Greg Stark<gsstark(at)mit(dot)edu> wrote:
>> I like the idea too, but I think there are some major problems to
>> solve. In particular I think we need a better solution to blocks
>> growing than sparse files.
>
> How much benefit does this approach have over using TOAST
> compression more aggressively?
I was wondering the same thing. It seems like compressing a page at a
time should allow more space savings than a column at a time, and
possibly do it faster.
One question I have banging around in my head is what to do with
out-of-line storage. Sometimes you have a large column which you know
contains data which is already compressed and/or encrypted, so
attempting compression would give little or no benefit; so I'm
inclined to think that if we do page compression, it shouldn't deal
with toast tables. We could leave them to the current techniques.
That leaves some subtle problems with how to deal with a datum which
currently compresses from, say, several kB down to one or two hundred
bytes. Current TOAST logic would typically compress and inline it.
What would we do if we're trying to push heap compression to the page
level?
-Kevin