Re: Re: Re: Postgres and Oracle differences and questions

Tom Lane wrote:
> Jan Wieck <janwieck(at)Yahoo(dot)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.

It does?

Uh - you're right. I wouldn't want to change it now, but ASAP
in the 7.2 cycle. Bruce, please add

* Don't decompress untouched toast values on UPDATE

to TODO.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com