I wrote:
> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
>> Now that I look at it: Why do we have a separate vacuum_cleanup function
>> at all? Calls to index_vacuum_cleanup go hand in hand with calls to
>> index_bulk_delete.
> Yeah, I was just thinking we ought to revisit that. The original idea
> was that vacuumcleanup would be called just once at the end of vacuuming,
> not once per bulkdelete. I don't recall why I changed it but it was
> probably a bad idea to do so.
I remember why: the design involves passing a palloc'd struct from
bulkdelete to vacuumcleanup and there needed to be matching calls to
make that behave sanely.
We could fix this if the API is something like "the first bulkdelete
call palloc's the struct, and *it's passed in to* each subsequent
bulkdelete, as well as being passed to vacuumcleanup". So we're short
one argument to bulkdelete. This would provide a saner way of dealing
with the case of nothing to delete, too: if vacuumcleanup gets a NULL
stats pointer, that means bulkdelete wasn't ever called (or was, but
chose never to return a non-null pointer).
Also, as noted in other contexts, it'd be a good idea if vacuumcleanup
was told the total number of heap tuples (GIN needs this), and both
steps really ought to be able to find out if it's a full or lazy vacuum.
I'll work on making these API changes; the recent GIN patch has left
some other detritus that needs to be cleaned up in the same area.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
