Re: Variable length varlena headers redux

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: Variable length varlena headers redux
Дата
Msg-id 87abzighid.fsf@stark.xeocode.com
обсуждение исходный текст
Ответ на Re: Variable length varlena headers redux  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Variable length varlena headers redux  (Bruce Momjian <bruce@momjian.us>)
Re: Variable length varlena headers redux  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> writes:

> > So (nigh) every tuple will get deformed and reformed once before it goes to
> > disk? Currently the toast code doesn't even look at a tuple if it's small
> > enough, but in this case we would want it to fire even on very narrow rows.
> 
> I'd be inclined to put the intelligence into heap_form_tuple and thereby
> avoid getting the TOAST code involved unless there are wide fields to
> deal with.

And have heap_deform_tuple / heap_getattr palloc and memcpy the the datum on
the way out? Or wait until detoast time and then do it?

If we do it on the way out of the heaptuple then we could have a rule that
headers are always compressed in a tuple and always uncompressed out of a
tuple.

But I'm surprised, I had the impression that you were reluctant to consider
memcpying all the data all the time.

-- 
greg



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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Variable length varlena headers redux
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Variable length varlena headers redux