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.

diff --git a/src/backend/access/heap/pruneheap.c b/src/backend/access/heap/pruneheap.c
index c7331d8108e5c3669e6e7b1c49349b9bb4af4c85..50ed76198c9ccde996061837652d78e242b459ea 100644 (file)
--- a/src/backend/access/heap/pruneheap.c
+++ b/src/backend/access/heap/pruneheap.c
@@ -190,6 +190,12 @@ heap_page_prune_opt(Relation relation, Buffer buffer)
 
                /* And release buffer lock */
                LockBuffer(buffer, BUFFER_LOCK_UNLOCK);
+
+               /*
+                * We avoid reuse of any free space created on the page by unrelated
+                * UPDATEs/INSERTs by opting to not update the FSM at this point.  The
+                * free space should be reused by UPDATEs to *this* page.
+                */
        }
 }
 
@@ -197,7 +203,8 @@ heap_page_prune_opt(Relation relation, Buffer buffer)
 /*
  * Prune and repair fragmentation in the specified page.
  *
- * Caller must have pin and buffer cleanup lock on the page.
+ * Caller must have pin and buffer cleanup lock on the page.  Note that we
+ * don't update the FSM information for page on caller's behalf.
  *
  * vistest is used to distinguish whether tuples are DEAD or RECENTLY_DEAD
  * (see heap_prune_satisfies_vacuum and
@@ -382,22 +389,6 @@ heap_page_prune(Relation relation, Buffer buffer,
        if (report_stats && ndeleted > prstate.ndead)
                pgstat_update_heap_dead_tuples(relation, ndeleted - prstate.ndead);
 
-       /*
-        * XXX Should we update the FSM information of this page ?
-        *
-        * There are two schools of thought here. We may not want to update FSM
-        * information so that the page is not used for unrelated UPDATEs/INSERTs
-        * and any free space in this page will remain available for further
-        * UPDATEs in *this* page, thus improving chances for doing HOT updates.
-        *
-        * But for a large table and where a page does not receive further UPDATEs
-        * for a long time, we might waste this space by not updating the FSM
-        * information. The relation may get extended and fragmented further.
-        *
-        * One possibility is to leave "fillfactor" worth of space in this page
-        * and update FSM with the remaining space.
-        */
-
        return ndeleted;
 }