Re: HOT latest patch - version 8

Поиск
Список
Период
Сортировка
Искать
От
Heikki Linnakangas
Тема
Re: HOT latest patch - version 8
Дата
Msg-id
4697C31A.6020409@enterprisedb.com
Ответ на
Список
Дерево обсуждения
HOT latest patch - version 8 "Pavan Deolasee" <pavan.deolasee@gmail.com>
Re: HOT latest patch - version 8 "Pavan Deolasee" <pavan.deolasee@gmail.com>
Re: HOT latest patch - version 8 Heikki Linnakangas <heikki@enterprisedb.com>
Re: HOT latest patch - version 8 Heikki Linnakangas <heikki@enterprisedb.com>
Re: HOT latest patch - version 8 "Simon Riggs" <simon@2ndquadrant.com>
Re: HOT latest patch - version 8 Greg Smith <gsmith@gregsmith.com>
Re: HOT latest patch - version 8 <korryd@enterprisedb.com>
Re: HOT latest patch - version 8 Heikki Linnakangas <heikki@enterprisedb.com>
Re: HOT latest patch - version 8 Tom Lane <tgl@sss.pgh.pa.us>
Re: HOT latest patch - version 8 Heikki Linnakangas <heikki@enterprisedb.com>
Re: HOT latest patch - version 8 Tom Lane <tgl@sss.pgh.pa.us>
Re: HOT latest patch - version 8 Heikki Linnakangas <heikki@enterprisedb.com>
Re: HOT latest patch - version 8 Gregory Stark <stark@enterprisedb.com>
Re: HOT latest patch - version 8 Michael Glaesemann <grzm@seespotcode.net>
Re: HOT latest patch - version 8 Heikki Linnakangas <heikki@enterprisedb.com>
Re: HOT latest patch - version 8 Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>
Re: HOT latest patch - version 8 Heikki Linnakangas <heikki@enterprisedb.com>
Re: HOT latest patch - version 8 "Pavan Deolasee" <pavan.deolasee@gmail.com>
Re: HOT latest patch - version 8 Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>
Michael Glaesemann wrote:
> On Jul 13, 2007, at 8:31 , Heikki Linnakangas wrote:
>> 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?

The thing is, it's relatively expensive to figure out where the next 
tuple starts. We need to scan all line pointers to do that. Though given 
that pruning all tuples on a page is a relatively expensive operation 
anyway, maybe it wouldn't be so bad.

>> 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?

Yes, Vacuum will 'defrag' the page.

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com
В списке pgsql-patches по дате отправления
От: Simon Riggs
Дата:
От: Jim C. Nasby
Дата:
FAQ