Re: [HACKERS] Arbitrary tuple size

From: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
To: Jan Wieck <jwieck(at)debis(dot)com>
Cc: PostgreSQL HACKERS <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: [HACKERS] Arbitrary tuple size
Date: 1999-07-08 15:53:58
Message-ID: 199907081553.LAA09036@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> Well,
>
> doing arbitrary tuple size should be as generic as possible.
> Thus I think the best place to do it is down in the heapam
> routines (heap_fetch(), heap_getnext(), heap_insert(), ...).
> I'm not 100% sure but nothing should access a heap relation
> going around them. Anyway, if there are places, then it's
> time to clean them up.
>
> What about adding one more ItemPointerData to the tuple
> header which holds the ctid of a DATA continuation tuple. If
> a tuple doesn't fit into one block, this will tell where to
> get the next chunk of tuple data building a chain until an
> invalid ctid is found. The continuation tuples can have a
> negative t_natts to be easily identified and ignored by
> scanning routines.
>
> By doing it this way we could also sqeeze out some currently
> wasted space. All tuples that get inserted/updated are added
> to the end of the relation. If a tuple currently doesn't fit
> into the freespace of the actual last block, that freespace
> is wasted and the tuple is placed into a new allocated block
> at the end. So if there is 5K freespace and another 5.5K
> tuple is added, the relation grows effectively by 10.5K!
>
> I'm not sure how to handle this with vacuum, but I believe
> Vadim is able to put some well placed goto's that make it.

I agree this is the way to go. There is nothing I can think of that is
limited to how large a tuple can be. It is just accessing it from the
heap routines that is the problem. If the tuple is alloc'ed to be used,
we can paste together the parts on disk and return one tuple. If they
are accessing the buffer copy directly, we would have to be smart about
going off the end of the disk copy and moving to the next segment.

The code is very clear now about accessing tuples or tuple copies.
Hopefully locking will not be an issue because you only need to lock the
main tuple. No one is going to see the secondary part of the tuple.

If Vadim can do MVCC, he certainly can handle this, with the help of
goto. :-)

--
Bruce Momjian | http://www.op.net/~candle
maillist(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ross J. Reedstrom 1999-07-08 16:06:43 CVS broken
Previous Message Bruce Momjian 1999-07-08 15:47:23 Re: [HACKERS] Delaying insertion of default values