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

Re: Locking end of indexes during VACUUM

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Locking end of indexes during VACUUM
Date: 2011-08-03 21:57:35
Message-ID: 24267.1312408655@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> What seems strange is that we make no attempt to check whether we have
> already identified all tuples being removed by the VACUUM. We have the
> number of dead tuples we are looking for and we track the number of
> tuples we have deleted from the index, so we could easily make this
> check early and avoid waiting.

> Can we avoid scanning all pages once we have proven we have all dead tuples?

That seems pretty dangerous to me, as it makes correctness of tuple
removal totally dependent on there not being any duplicates, etc.
I don't think there's a sufficiently compelling performance argument
here to justify making VACUUM more fragile.

(In any case, since VACUUM is visiting the leaf pages in physical not
logical order, it's hard to argue that there would be any clear win for
specific application access patterns such as "hitting the largest keys a
lot".)

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Jim NasbyDate: 2011-08-03 22:05:21
Subject: Re: Compressing the AFTER TRIGGER queue
Previous:From: Tom LaneDate: 2011-08-03 21:35:57
Subject: Re: mosbench revisited

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