Skip site navigation (1) Skip section navigation (2)


From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: VACUUMs and WAL
Date: 2008-10-28 10:59:51
Message-ID: (view raw or whole thread)
Lists: pgsql-hackers
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.

  Gregory Stark
  Ask me about EnterpriseDB's 24x7 Postgres support!

In response to


pgsql-hackers by date

Next:From: Simon RiggsDate: 2008-10-28 11:04:51
Subject: Re: VACUUMs and WAL
Previous:From: Gregory StarkDate: 2008-10-28 10:50:59
Subject: Re: Proposal of PITR performance improvement for 8.4.

Privacy Policy | About PostgreSQL
Copyright © 1996-2015 The PostgreSQL Global Development Group