Simon Riggs <simon(at)2ndQuadrant(dot)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 and b) 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
There might also have been a question of how to deal with the statistics.
Ask me about EnterpriseDB's 24x7 Postgres support!
In response to
pgsql-hackers by date
|Next:||From: Simon Riggs||Date: 2008-10-28 11:04:51|
|Subject: Re: VACUUMs and WAL|
|Previous:||From: Gregory Stark||Date: 2008-10-28 10:50:59|
|Subject: Re: Proposal of PITR performance improvement for 8.4.|