Re: vacuum, performance, and MVCC

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: vacuum, performance, and MVCC
Дата
Msg-id Pine.OSF.4.61.0606242148480.44498@kosh.hut.fi
обсуждение исходный текст
Ответ на Re: vacuum, performance, and MVCC  (Bruce Momjian <bruce@momjian.us>)
Ответы Re: vacuum, performance, and MVCC  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers
On Sat, 24 Jun 2006, Bruce Momjian wrote:

> OK, I have an idea.  Right now, an UPDATE where the old and new rows are
> on the same page have two index entries.  What if we made only one index
> entry for both?  We already have UPDATE chaining, where the old row
> points to the new one.  If no key columns change, we set a bit in the
> heap that the chaining points to the old and new row (both on the same
> page), so an index scan uses one index entry to see the old and new row,
> and once the old row is no longer visible, the page index id can be
> updated to point to the new row and the old row can be marked free and
> perhaps used for a future UPDATE.  (UPDATE already tries to do keep
> updates on the same heap page.)

In fact, that's what I originally thought Mark was suggesting. A couple of 
points:

Why the limitation of old and new row being on the same page?

This only works if none of the updated columns are indexed. That's a bit 
annoying. It would be nice to be able to create new index tuples in those 
indexes that contain one of the changed columns, but not in others.

What happens if you create a new index that contains one of 
the changed columns?

- Heikki


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

Предыдущее
От: "Magnus Hagander"
Дата:
Сообщение: Re: Crash on initdb in MSVC++
Следующее
От: Jan Wieck
Дата:
Сообщение: Re: vacuum, performance, and MVCC