Re: HOT latest patch - version 8
От | Michael Glaesemann |
---|---|
Тема | Re: HOT latest patch - version 8 |
Дата | |
Msg-id | E3A06796-856F-40B5-B312-D7C5FBD5AC14@seespotcode.net обсуждение исходный текст |
Ответ на | Re: HOT latest patch - version 8 (Heikki Linnakangas <heikki@enterprisedb.com>) |
Ответы |
Re: HOT latest patch - version 8
|
Список | pgsql-patches |
Heikki, Thanks for providing this summary. As someone unfamiliar with the domain (both HOT development specifically and tuple management in general), I found it easy to follow. On Jul 13, 2007, at 8:31 , Heikki Linnakangas wrote: > Pruning > ------- > To reclaim the index-visible (i.e. first) tuple in a HOT chain, the > line pointer is turned into a redirecting line pointer that points > to the line pointer of the next tuple in the chain. To keep track > of the space occupied by the dead tuple, so that we can reuse the > space, a new line pointer is allocated and marked with LP_DELETE to > point to the dead tuple. That means its tid changes, but that's ok > since it's dead. > Row-level fragmentation > ----------------------- > If there's no LP_DELETEd tuples large enough to fit the new tuple > in, the row-level fragmentation is repaired in the hope that some > of the slots were actually big enough, but were just fragmented. > That's done by mapping the offsets in the page, and enlarging all > LP_DELETEd line pointers up to the beginning of the next tuple. Would it make sense to enlarge the LP_DELETEd line pointers up to the beginning of the next tuple at the time the tuple is marked LP_DELETE? > Vacuum > ------ > Vacuum prunes all HOT chains, and removes any LP_DELETEd tuples, > making the space available for any use. In the case of a fragmented row, am I right to assume vacuum reclaims all space up to the next (live) tuple? Michael Glaesemann grzm seespotcode net
В списке pgsql-patches по дате отправления: