Re: [HACKERS] LONG

Peter Eisentraut wrote:

> On Sat, 11 Dec 1999, Bruce Momjian wrote:
>
> > In fact, you could get fancy and allow an update of a non-pg_long using
> > column to not change pg_long at all.  Just keep the same value in the
> > column.  If the transaction fails or succeeds, the pg_long is the same
> > for that tuple.  Of course, because an update is a delete and then an
> > insert, that may be hard to do.  For very long fields, it would be a win
> > for UPDATE.  You certainly couldn't do that with chained tuples.
>
> While this is great and all, what will happen when long tuples finally get
> done? Will you remove this, or keep it, or just make LONG and TEXT
> equivalent? I fear that elaborate structures will be put in place here
> that might perhaps only be of use for one release cycle.

    With  the  actual  design  explained, I don't think we aren't
    that much in need for long tuples any more,  that  we  should
    introduce  all  the  problems  of  chaninig  tuples  into the
    vacuum, bufmgr, heapam, hio etc. etc. code.

    The rare cases, where someone really needs larger tuples  and
    not  beeing  able  to  use the proposed LONG data type can be
    tackled by increasing BLKSIZE for this specific installation.

    Isn't  there  a FAQ entry about "tuple size too big" pointing
    to BLKSIZE?  Haven't checked, but if it is, could that be the
    reason why we get lesser request on this item?


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) #