Re: Re: Re: Postgres and Oracle differences and questions - Mailing list pgsql-interfaces

Tom Lane wrote:
> 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.
   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@Yahoo.com #



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