Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
>> It seems like it might be reasonable to have a separate threshold
>> for compression from that for out-of-line storage. Since I've been
>> in that code recently, I would be pretty comfortable doing
>> something about that; but, as is so often the case, the problem
>> will probably be getting agreement on what would be a good change.
> I'm not clear how this would work. The toast code is designed
> around hitting a target for the overall tuple size; how would it
> make sense to treat compression and out-of-lining differently?
The current steps are:
1: Inline compress attributes with attstorage 'x', and store very large attributes with attstorage 'x' or 'e' external
immediately
2: Store attributes with attstorage 'x' or 'e' external
3: Inline compress attributes with attstorage 'm'
4: Store attributes with attstorage 'm' external
If we had separate compression and external storage tuple targets:
Is there any reason not to include 'm' in the first inline compression
phase (step 1)? It does seem reasonable to store "very large
attributes" externally in the first pass, but it would be pretty easy
to include 'm' in the compression but skip it for the external storage
during step 1. In this phase we would use the compression target.
Step 2 would use the target tuple size for external storage, which
would probably usually be >= the compression target. If we want to
allow a compression target > external storage target, I guess we would
have to allow the smaller target to go first; however, I'm not really
sure if there is a sane use case for a larger compression target than
external storage target.
Step 3 would go away, since its work could be moved to step 1.
Step 4 would maintain the behavior created by the recent patch.
> And especially, how could you have per-column targets?
>
> I could see having a reloption that allowed per-table adjustment of
> the target tuple width...
Yeah, this would have to be done by table, not by column.
The compression configuration mentioned by Laurent, if we want to make
that tunable, which could make sense by column; but the toast tuple
sizes targets would clearly need to be by table.
-Kevin
