Re: [HACKERS] Volunteer: Large Tuples / Tuple chaining

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: [HACKERS] Volunteer: Large Tuples / Tuple chaining
Дата
Msg-id 199912140159.UAA22328@candle.pha.pa.us
обсуждение исходный текст
Ответ на Volunteer: Large Tuples / Tuple chaining  (Christof Petig <christof.petig@wtal.de>)
Список pgsql-hackers
Thanks.  Seems like Jan is going to be doing this.


> Hello,
> 
> I'll donate some (read all freely available) of my spare time to
> implementing tuple
> chaining. It looks like this feature is most wanted and it would be a
> pity to hold this until post 7.0. Personally I don't need it, yet ...
> But I will definitely find a use for it once available ;-) And it looks
> like a good start for hacking on pgsql.
> 
> I already dived into the depth of pgsql's page and tuple structures and
> it looks like it is possible. But before I start coding I would like to
> hear some more experienced opinions on how to implement it.
> 
> Did you alread discuss technical matters about the implementation? How
> can I get in touch with it? (Simply browse the mailing list archives?)
> 
> Here's a layout how I imagine the work:
> 
> What is needed:
> - lay out a tuple continuation structure
> - put tuple into multiple chunks when pages are considered, reconcile
> when
>   loaded from disk
>   (how to continue a tuple - need a structure)
>   how is a tuple (read page item) addressed? ItemPointerData
>   I imagine to store a continuation address as the last bytes of the
> tuple unless it
>   fits into one page.
>   I need to mark large tuples (how, just one flag in tuple)
>   How to tell a maximum possible size last block from a continued 
>   (which carries a pointer to the next one at its end)? 
>   Or don't care: make item continued and put last 6(?) bytes into a new
> block
> - note that the continued tuples are not referenced directly (vacuum?)
>   mark them as used. I hope vacuum operates on a tuple basis and has no
> concept of
>   pages
> - I guess that the tuple pointer points into page memory, if multiple
> pages 
>   are concatenated for a tuple, these pages must not reside in memory
> but
>   the full tuple's memory must be allocated (from a memory similar to
> pages)
>   (shared mem?)
> - should be possible for memory only pages 
>   see PageGetPageSize but od_pagesize is 16bit!
>   Reuse another variable? Another type of page? (32bit od_pagesize)
>   
> Very fascinated by this large beast of ancient code to explore
>       Christof
> 
> PS: I think the documentation on page layout is far outdated (or points
> into the future since it speaks about ItemContinuationData structures.)
> Should I update it?
> The table doesn't match actual structure components. At least I don't
> understand what it's about. The source code mentions a different page
> layout.
> 
> PPS: Do not pity me, I have ten+ years of coding experience in C.
> 
> PPPS: Could someone in few words tell me what an access method is (a
> tuple is an access method, log pages are another?)
> 
> 
> ************
> 


--  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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] pg_createuser
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] LONG