Simon Riggs <simon@2ndQuadrant.com> writes:
> I don't see a reason why we would issue 2 WAL records per block for a
> VACUUM, nor why we would prune and remove in two steps, dirtying the
> block each time. Seems like we could write approximately half the amount
> of data that we do.
>
> Surely we can come up with a better plan than that one?
This sounds like the same issue Pavan identified and proposed solving by
rotating the three passes so that we do step 3 at the beginning of the next
vacuum run, so it can be done in the same pass as step 1.
To do that he proposed we do:
1. scan heap doing two things: a) remove any marked tuples if they were marked by a previous vacuum which committed
andb) prune and mark any tuples we find are deletable for a future vacuum to remove.
2. scan indexes and remove the tuples we marked in 1b.
The main blocking issue IIRC was:
How to mark the tuples in a way which is safe if vacuum aborts. He suggested
putting a vacuum xid in pg_class. Other suggestions were to mark the pages in
the page header (which I thought made the most sense) or to put the xid in the
line pointer (since nothing else needs to go there, the tuples are already
cleaned).
There might also have been a question of how to deal with the statistics.
-- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support!