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(at)debis(dot)com (Jan Wieck) #