Re: [HACKERS] Arbitrary tuple size

Vadim wrote:

>
> Bruce Momjian wrote:
> >
> > > Bruce Momjian wrote:
> > > >
> > > > If we get wide tuples, we could just throw all large objects into one
> > > > table, and have an on it.  We can then vacuum it to compact space, etc.
> > >
> > > Storing 2Gb LO in table is not good thing.
> > >
> > > Vadim
> > >
> >
> > Ah, but we have segemented tables now.  It will auto-split at 1 gig.
>
> Well, now consider update of 2Gb row!
> I worry not due to non-overwriting but about writing
> 2Gb log record to WAL - we'll not be able to do it, sure.
>
> Isn't it why Informix restrict tuple len to 32k only?
> And the same is what Oracle does.
> Both of them have ability to use > 1 page for single row,
> but they have this restriction anyway.
>
> I don't like _arbitrary_ tuple size.
> I vote for some limit. 32K or 64K, at max.

    To  have  some  limit seems reasonable for me (I've also read
    the other comments). When dealing with regular tuples,  first
    off  the  query  to  insert or update them will get read into
    memory.  Next the querytree with the  Const  vars  is  built,
    rewritten,  planned.  Then  the  tuple is built in memory and
    maybe somewhere else copied (fulltext index trigger).  So the
    amount of memory will be allocated many times!

    There  is  some  natural limit on the tuple size depending on
    the  available  swapspace.  Not  everyone  has  multiple   GB
    swapspace  setup.  Making  it  a  well  known hard limit that
    doesn't hurt even if 20 backends do things simultaneously  is
    better.

    I vote for a limit too. 64K should be enough.


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