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?
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
# 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
In response to
pgsql-interfaces by date
|Next:||From: Jan Wieck||Date: 2001-02-08 13:10:11|
|Subject: Re: PostgreSQL and PHP persistent connections|
|Previous:||From: Jan Wieck||Date: 2001-02-08 12:10:08|
|Subject: Re: pl/perl and security|