Re: [HACKERS] Arbitrary tuple size

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: [HACKERS] Arbitrary tuple size
Дата
Msg-id 199907081553.LAA09036@candle.pha.pa.us
обсуждение исходный текст
Ответ на Arbitrary tuple size  (wieck@debis.com (Jan Wieck))
Ответы Re: [HACKERS] Arbitrary tuple size  (wieck@debis.com (Jan Wieck))
Re: [HACKERS] Arbitrary tuple size  (wieck@debis.com (Jan Wieck))
Список 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@candle.pha.pa.us            |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Lamar Owen
Дата:
Сообщение: Re: [Fwd: [HACKERS] Re: Postgresql 6.5-1 rpms on RedHat 6.0]
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] Updated TODO list