Simon Riggs <[EMAIL PROTECTED]> writes:
> That wasn't the proposal. Every split would be marked and stay marked
> until those blocks were VACUUMed. The data used to mark is readily
> available and doesn't rely on whether or not VACUUM is running.
> IMHO this does work.
OK, I misunderstood what you had in mind, but now that I do understand
it doesn't seem terribly efficient. What you're suggesting is that we
take as a "vacuum group" all the pages that have been split off from a
single original page since that page was last vacuumed, and that this
group must be vacuumed as a whole. That works, but it seems that the
groups would get awfully large. In particular, this substantially
penalizes btbulkdelete in hopes of someday improving matters for what
remains an entirely fictional partial vacuum. As it stands today,
btbulkdelete only has to worry about page groups formed since it began
to run, not since the last vacuum. Changing the data representation
like this would force it to retrace much more often and over much larger
page groups.
>> (The other little problem is that we'd have to enlarge the BTOpaque
>> overhead, because a block id doesn't fit in the available 16 bits.)
> ISTM it is indeed a little problem. After CREATE INDEX, most index pages
> don't stay completely full, so worrying about alignment wastage might
> very occasionally save an I/O, but not enough for us to care.
I don't think an extra 4 or 8 bytes need be a show-stopper, but it does
force an initdb and thus make it harder to compare the two techniques.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
