Duplicating transaction information in indexes and performing in memory vacuum

Поиск
Список
Период
Сортировка
От Shridhar Daithankar
Тема Duplicating transaction information in indexes and performing in memory vacuum
Дата
Msg-id 3F9CF924.4020104@myrealbox.com
обсуждение исходный текст
Ответы Re: Duplicating transaction information in indexes and performing in memory vacuum  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Hi,

Last week, there was a thread whether solely in memory vacuum can be performed 
or not.(OK, that was a part of thread but anyways)

I suggested that a page be vacuumed when it is pushed out of buffer cache. Tom 
pointed out that it can not be done as index tuples stote heap tuple id and 
depend upon heap tuple to find out transaction information.

I asked is it feasible to add transaction information to index tuple and the 
answer was no.

I searched hackers archive and following is only thread I could come up in this 
context.

http://archives.postgresql.org/pgsql-hackers/2000-09/msg00513.php
http://archives.postgresql.org/pgsql-hackers/2001-09/msg00409.php

The thread does not consider vacuum at all.

What are (more) reasons for not adding transaction information to index tuple, 
in addition to heap tuple?

Cons are bloated indexes. The index tuple size will be close to 30 bytes minimum.

On pro* side of this, no more vacuum required (at least for part of data that is 
being used. If data isn't used, it does not need vacuum anyway) and space bloat 
is stopped right in memory, without incurring overhead of additional IO vacuum 
demands.

Given recent trend of pushing PG higher and higher in scale (From performance 
list traffic, that is), I think this could be worthwhile addition.

So what are the cons I missed so far?
 Bye  Shridhar



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

Предыдущее
От: Carlos Guzmán Álvarez
Дата:
Сообщение: Re: Question about read interval type in binary format
Следующее
От: strk
Дата:
Сообщение: Aggregate detoasted arguments lifetime