Re: Per tuple overhead, cmin, cmax

Поиск
Список
Период
Сортировка
От Manfred Koizar
Тема Re: Per tuple overhead, cmin, cmax
Дата
Msg-id ejf4du853mblm44f0u78f02g166r69lng7@4ax.com
обсуждение исходный текст
Ответ на Re: Per tuple overhead, cmin, cmax  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Thu, 02 May 2002 21:10:40 -0400, Tom Lane wrote:

>Hmm ... that might work.  Actually, we are trying to stuff *five*
>numbers into these fields: xmin, xmax, cmin, cmax, and a VACUUM FULL
>transaction id (let's call it xvac just to have a name).  The code
>currently assumes that cmin is not interesting simultaneously with xvac.
>I think it might be true that cmax is not interesting simultaneously
>with xvac either, in which case this could be made to work.  (Vadim,
>your thoughts?)
Having read the sources recently I'm pretty sure you're right.

>I'm on the fence about it.  My thoughts are probably colored by the
>fact that I prefer platforms that have MAXALIGN=8, so half the time
>(including all null-free rows) there'd be no savings at all.
But the other half of the time we'd save 8 bytes.  So on average we
get savings of 4 bytes per tuple, don't we?

> Now if
>we could get rid of 8 bytes in the header, I'd get excited ;-)
I keep trying :-)

ServusManfred


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

Предыдущее
От: Manfred Koizar
Дата:
Сообщение: Trying to reduce per tuple overhead (bitmap)
Следующее
От: Bradley Kieser
Дата:
Сообщение: Re: a vulnerability in PostgreSQL