Re: Index tuple killing code committed

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Index tuple killing code committed
Дата
Msg-id 21622.1022278146@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Index tuple killing code committed  (Joe Conway <mail@joeconway.com>)
Список pgsql-hackers
Joe Conway <mail@joeconway.com> writes:
> This may qualify as a "way out there" idea, or more trouble than it's 
> worth, but what about a table option which provides a bitmap index of 
> tuple status -- i.e. tuple dead t/f. If available, a seqscan in between 
> vacuums could maybe gain some of the same efficiency.

Hmm.  I'm inclined to think that a separate bitmap index wouldn't be
worth the trouble.  Under most scenarios it'd just require extra I/O
and not buy much.

However ... we could potentially take over the LP_DELETED flag bit of
heap tuples for the same use as for index tuples: set it when the tuple
is known dead for all transactions.  This would save calling
HeapTupleSatisfiesSnapshot in the inner loop of heapgettup, while not
adding much expense for the normal case where the tuple's not dead.
        regards, tom lane


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

Предыдущее
От: Hannu Krosing
Дата:
Сообщение: Re: Index tuple killing code committed
Следующее
От: Joe Conway
Дата:
Сообщение: Re: Redhat 7.3 time manipulation bug