Re: heap_page_prune comments

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Fri, Nov 4, 2011 at 10:46 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> IIRC, this code is following the very longstanding precedent of
>> RelationGetBufferForTuple.

> I don't understand the analogy - that function isn't freeing any
> space, just searching for a block that already has some. And it does
> update the free space map if the free space map is found to be out of
> date, whereas this function does not.

No, I'm talking about what it does at the very bottom, when it's had to
add a new block to the relation:

* XXX should we enter the new page into the free space map immediately,
* or just keep it for this backend's exclusive use in the short run
* (until VACUUM sees it)? Seems to depend on whether you expect the
* current backend to make more insertions or not, which is probably a
* good bet most of the time. So for now, don't add it to FSM yet.

Now, heap_page_prune is in a slightly different place, because it
doesn't actually know whether the current backend is going to make an
insertion or update in the page. If it did know that was going to
happen, then the analogy would be exact.

In any case, the comment in heap_page_prune is ignoring the probability
that VACUUM will eventually visit the page and then update the FSM.
That ought to be factored into any discussion of what to do here.

regards, tom lane