Re: HOT patch - version 15
От | Heikki Linnakangas |
---|---|
Тема | Re: HOT patch - version 15 |
Дата | |
Msg-id | 46E57D7C.5040001@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: HOT patch - version 15 (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: HOT patch - version 15
Re: HOT patch - version 15 Re: HOT patch - version 15 |
Список | pgsql-patches |
Bruce Momjian wrote: > My guess is that once you prune a tuple > you no longer have to check its visibility, and that is where the win is > coming from. Yes, I think that's right. Oh, one more thing occured to me. Without HOT, we not only mark index tuples pointing to dead tuples as killed, we remove them altogether if the index page gets full. If you modify the test case so that after doing the updates, you insert a bunch of tuples with a different key to fill the index page, you should see CVS HEAD winning HOT without pruning hands down. > If we check a tuple in a chain and the tuple is dead is it possible the > pruning operation is cheaper than having to check the tuple again for > visibility the next time we see it? If so, we can just always prune > when we see a dead tuple in the chain, which I believe was the original > design. Pruning becomes an operation similar to marking an index entry > as dead. (I assuming pruing does not generate WAL traffic.) Pruning does generate a WAL record at the moment. Maybe you could do some kind of a quick pruning without a WAL record. Like just modify the ctid of the oldest dead tuple in the chain, or the redirecting line pointer if there is one, to point to the latest live tuple, without removing the dead tuples or the line pointers. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-patches по дате отправления: