Re: [HACKERS] generic LONG VARLENA

Tom Lane wrote:

> wieck@debis.com (Jan Wieck) writes:
>
> Per-type control doesn't strike me as interesting or useful.  If there
> needs to be a control at all, which I doubt, per-table would be the

    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.  If  we  finally  have  all
    builtin types finished for LONG handling, it will be removed,
    making user defined types LONGable too.

> >     I  don't  think  it  is  a  good idea to create the expansion
> >     relation all the time. Some keyword in CREATE  TABLE,  and/or
> >     another ALTER TABLE should do it instead, so the DB admin can
> >     activate the LONG feature on a per table base as  needed.
>
> I don't believe it.  See above: people will complain that it's a bug
> that the system doesn't handle their long data values.  Saying "oh, you
> have to turn it on" will not appease them.  My objection is really the
> same as for the specialized LONG datatype: I do *not* want people to
> have to put nonstandard junk into their database schema declarations
> in order to activate this feature.  I think it should Just Work and
> stay out of users' faces.
>
> Creating the expansion relation isn't that big a deal, but if you
> don't want to do it always, why not do it on first use?

    So  you  want  to  do   a   heap_create_with_catalog()   plus
    index_create()'s    from    inside   the   heap_insert()   or
    heap_update(). Cannot be done  from  anywhere  else,  because
    that's  the point where we recognize the need.  I don't think
    that's a good idea. What would happen if

      Xact 1 needs expansion relation and creates it.
      Xact 2 needs expansion relation too and uses that one
      Xact 1 aborts
      Xact 2 commits

    Better to put out an explanative error message if  tuple  too
    big  and  no  expansion  relation  exists,  than dealing with
    trouble when autocreating it. If it later turns out  that  it
    can  safely  work  as an automated process, we can do it in a
    subsequent release.

> >     Also  I  would  like to say that system relations cannot have
> >     expansion relations.  At  least  not  until  we  have  enough
> >     experience with this stuff.
>
> I'd really, really, really like to have this work for rules, though.
> Why shouldn't we allow it for system relations?  Most of the critical
> ones have fixed-width tuples anyway, so it won't matter for them.

    Me too, and for function source text again.

    But this time, you  include  the  syscache  into  the  entire
    approach too.

> 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.

> >     Is  that  now  what we initially want to give a try? If so, I
> >     would like to start soon to get the generic part ready  ASAP.
> >     Others  could  then  join  in  and  contribute by adding LONG
> >     support for all the VARLENA data types we have.
>
> Yes, if we don't do it inside fastgetattr then there's a lot of code
> that will have to change.

    That's  why  I'd  like  a  small  number of types involved at
    first.

    And there we're back  on  the  "release  what  we  have  now"
    discussion  again.  Some like to get new functionality out in
    a couple of smaller steps,  than  doing  the  big  all-in-one
    roll.  Some  not.  Seems we can never get a consensus on that
    :-(


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#========================================= wieck@debis.com (Jan Wieck) #