Re: HOT patch - version 15
От | Bruce Momjian |
---|---|
Тема | Re: HOT patch - version 15 |
Дата | |
Msg-id | 200709101917.l8AJHCV15018@momjian.us обсуждение исходный текст |
Ответ на | Re: HOT patch - version 15 ("Heikki Linnakangas" <heikki@enterprisedb.com>) |
Ответы |
Re: HOT patch - version 15
|
Список | pgsql-patches |
Heikki Linnakangas wrote: > 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. I am wondering what you even mean by removing the dead tuples when pruning. I thought only defragmentation removed tuples. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
В списке pgsql-patches по дате отправления: