Jan Wieck <janwieck@Yahoo.com> writes:
> Tom Lane wrote:
>> Speaking of which, though, it looks like an update or insert will
>> forcibly uncompress (and later recompress) a compressed-in-line datum,
>> which seems like a waste of cycles to me. Jan, shouldn't the test for
>> VARATT_IS_EXTENDED at line 357 instead read VARATT_IS_EXTERNAL?
> Not without some more logic added.
> We don't have any admin commands yet that can modify the
> toasters strategy on the attribute level, but the config
> attributes in the tuple descriptor are already there. So you
> can tell the toaster per attribute if it should try to
> compress or not, if it should try to keep the attribute in
> the main tuple harder and the like. You have to modify
> pg_attribute yourself for now, where we might want to have
> some ALTER TABLE, don't we?
What's your point here? I wouldn't think that changing the strategy
for a column to "plain" should mean that already-stored values get
uncompressed when they're not being modified. Someone who did expect
that would probably want the ALTER TABLE command to go through and
redo the representation of each row immediately, anyway.
ISTM what's really at stake is simply how fast does a strategy change
propagate to the individual rows of a table. Given that the strategy
values are mostly just hints anyway, it's not clear to me why you
insist that changing "x" to "p" must cause decompression at the first
touch of a row containing a value, and not either earlier (immediately
upon strategy-altering command) or later (when the value in question
is actually replaced with something different).
> IIRC the above should only be invoked if you do something
> like INSERT ... SELECT, where the already toasted value is
> coming from another tuple than the one you're actually
> creating/updating.
No, the problem comes up in a plain UPDATE, if it's altering other
fields in the same row. Look again at the code: the comment claims
that the UPDATE case has been taken care of above, but that is true
only for an externally stored value. So a compressed-in-line field
that has been copied from the old tuple will be uncompressed and
(presumably) recompressed by the current logic. I say that's silly;
we should not pay a performance penalty that large just to have a very
subtly different speed of response to strategy-altering commands that
don't exist yet.
regards, tom lane