Re: [HACKERS] generic LONG VARLENA - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] generic LONG VARLENA
Date
Msg-id 7635.945055904@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] generic LONG VARLENA  (wieck@debis.com (Jan Wieck))
Responses Re: [HACKERS] generic LONG VARLENA
List pgsql-hackers
wieck@debis.com (Jan Wieck) writes:
> Tom Lane wrote:
>> Per-type control doesn't strike me as interesting or useful.

>     Isn't   intended  to  be  a  runtime  configuration.  Just  a
>     temporary feature to restrict  the  attributes  that  can  be
>     moved  off  to  those  types,  where  WE  know  that  the adt
>     functions are prepared for  them.

Oh, I see.  Yeah, if we wanted to make an interim release where only
some datatypes were ready for long values, that would be a necessary
safety measure.  But I'd rather plan on just getting it done in one
release.

>> BTW, it strikes me we should drop the "lztext" special datatype, and
>> instead have compression automatically applied to any varlena that
>> we are contemplating putting out-of-line.  (If we're really lucky,
>> that saves us having to put the value out-of-line!)

>     Nice   idea,   and  should  be  technically  easy  since  the
>     compressor itself is separated from the lztext type. OTOH the
>     user  then  will  have no choice to prevent compression tries
>     for performance reasons.
>     So this feature again is something that IMHO should go into a
>     configurable option.

Good point.  You're right, there should be a per-datatype "don't
bother to try to compress this type" flag.  (Is per-datatype the
right granularity?)
        regards, tom lane


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] LONG
Next
From: wieck@debis.com (Jan Wieck)
Date:
Subject: Re: [HACKERS] generic LONG VARLENA