Skip site navigation (1) Skip section navigation (2)

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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jan Wieck <janwieck(at)Yahoo(dot)com>
Cc: Hannu Krosing <hannu(at)tm(dot)ee>, "D(dot) Johnson" <dspectra(at)home(dot)com>, pgsql-interfaces(at)postgresql(dot)org
Subject: Re: Re: Re: Postgres and Oracle differences and questions
Date: 2001-02-08 15:00:57
Message-ID: 11884.981644457@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-interfaces
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.

			regards, tom lane

In response to

Responses

pgsql-interfaces by date

Next:From: Steve WranovskyDate: 2001-02-08 19:28:57
Subject: 7.1 beta 3 Linux ODBC BEGIN Behaviour
Previous:From: Colin.HillDate: 2001-02-08 14:36:43
Subject: ODBC for ver 7 (Windows 2000)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group