Re: "Truncated" tuples for tuple hash tables

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: "Truncated" tuples for tuple hash tables
Дата
Msg-id 29231.1151333819@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: "Truncated" tuples for tuple hash tables  (Martijn van Oosterhout <kleptog@svana.org>)
Список pgsql-hackers
Martijn van Oosterhout <kleptog@svana.org> writes:
> On Mon, Jun 26, 2006 at 10:36:00AM -0400, Tom Lane wrote:
>> Unlike the case with sort temp files, it's important to be able to
>> access the stored data without moving/copying it.  So, not wishing to
>> duplicate all the tuple access machinery we have already, I'm
>> envisioning a compromise design that leaves a couple bytes on the table
>> but looks enough like a standard tuple to be directly usable.

> I considered this, but ran into the problem that heap_getattr fell back
> to fastgetattr, which wouldn't know what kind of tuple it was given.
> Now, if you're going to add a special heap_getattr for these tuples,
> then ofcourse there's no problem.

No, I'm specifically *not* going to do that.  AFAICS the proposed
representation requires no changes in heap_getattr; if it did, it'd
be too invasive to contemplate :-(.  It should look exactly like any
other HeapTuple structure, except that the "transaction status" fields
will contain garbage.  Do you see something I missed?
        regards, tom lane


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

Предыдущее
От: Hannu Krosing
Дата:
Сообщение: Re: vacuum, performance, and MVCC
Следующее
От: Martijn van Oosterhout
Дата:
Сообщение: Re: vacuum, performance, and MVCC