Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit 42f9427

Browse files
Update heap_page_prune() free space map comments.
It is up to the heap_page_prune() caller to decide what to do about updating the FSM for a page following pruning. Update old comments that address what we might want to do as if it was the responsibility of heap_page_prune() itself. heap_page_prune() doesn't have enough high-level context to make a sensible choice.
1 parent eb9baef commit 42f9427

File tree

1 file changed

+8
-17
lines changed

1 file changed

+8
-17
lines changed

src/backend/access/heap/pruneheap.c

+8-17
Original file line numberDiff line numberDiff line change
@@ -190,14 +190,21 @@ heap_page_prune_opt(Relation relation, Buffer buffer)
190190

191191
/* And release buffer lock */
192192
LockBuffer(buffer, BUFFER_LOCK_UNLOCK);
193+
194+
/*
195+
* We avoid reuse of any free space created on the page by unrelated
196+
* UPDATEs/INSERTs by opting to not update the FSM at this point. The
197+
* free space should be reused by UPDATEs to *this* page.
198+
*/
193199
}
194200
}
195201

196202

197203
/*
198204
* Prune and repair fragmentation in the specified page.
199205
*
200-
* Caller must have pin and buffer cleanup lock on the page.
206+
* Caller must have pin and buffer cleanup lock on the page. Note that we
207+
* don't update the FSM information for page on caller's behalf.
201208
*
202209
* vistest is used to distinguish whether tuples are DEAD or RECENTLY_DEAD
203210
* (see heap_prune_satisfies_vacuum and
@@ -382,22 +389,6 @@ heap_page_prune(Relation relation, Buffer buffer,
382389
if (report_stats && ndeleted > prstate.ndead)
383390
pgstat_update_heap_dead_tuples(relation, ndeleted - prstate.ndead);
384391

385-
/*
386-
* XXX Should we update the FSM information of this page ?
387-
*
388-
* There are two schools of thought here. We may not want to update FSM
389-
* information so that the page is not used for unrelated UPDATEs/INSERTs
390-
* and any free space in this page will remain available for further
391-
* UPDATEs in *this* page, thus improving chances for doing HOT updates.
392-
*
393-
* But for a large table and where a page does not receive further UPDATEs
394-
* for a long time, we might waste this space by not updating the FSM
395-
* information. The relation may get extended and fragmented further.
396-
*
397-
* One possibility is to leave "fillfactor" worth of space in this page
398-
* and update FSM with the remaining space.
399-
*/
400-
401392
return ndeleted;
402393
}
403394

0 commit comments

Comments
 (0)