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

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?


Reply via email to