Re: In-place index updates and HOT (Was: [HACKERS] Patch: WriteAmplification Reduction Method (WARM))

Поиск
Список
Период
Сортировка
От Claudio Freire
Тема Re: In-place index updates and HOT (Was: [HACKERS] Patch: WriteAmplification Reduction Method (WARM))
Дата
Msg-id CAGTBQpZW7g0qPUJz863gJ2BM08G_J3e-y5wOLSPkGo5PGWiCFw@mail.gmail.com
обсуждение исходный текст
Ответ на In-place index updates and HOT (Was: [HACKERS] Patch: WriteAmplification Reduction Method (WARM))  (Peter Geoghegan <pg@bowt.ie>)
Ответы Re: In-place index updates and HOT (Was: [HACKERS] Patch: WriteAmplification Reduction Method (WARM))  (Peter Geoghegan <pg@bowt.ie>)
Список pgsql-hackers
On Fri, Jul 28, 2017 at 8:32 PM, Peter Geoghegan <pg@bowt.ie> wrote:
> README.HOT says that that cost is not worth the benefit of
> preventing a new index write, but I think that it ought to take into
> account that not all index writes are equal. There is an appreciable
> difference between inserting a new tuple, and updating one in-place. We
> can remove the cost (hurting new snapshots by making them go through old
> heap pages) while preserving most of the benefits (no logically
> unnecessary index bloat).

It's a neat idea.

And, well, now that you mention, you don't need to touch indexes at all.

You can create the new chain, and "update" the index to point to it,
without ever touching the index itself, since you can repoint the old
HOT chain's start line pointer to point to the new HOT chain, create
a new pointer for the old one and point to it in the new HOT chain's
t_tid.

Existing index tuples thus now point to the right HOT chain without
having to go into the index and make any changes.

You do need the new HOT chain to live in the same page for this,
however.



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] AlterUserStmt anmd RoleSpec rules in grammar.y
Следующее
От: fan yang
Дата:
Сообщение: [HACKERS] Memory leak