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