Re: lazy vacuum sleeps with exclusive lock on table - Mailing list pgsql-hackers

From Tom Lane
Subject Re: lazy vacuum sleeps with exclusive lock on table
Date
Msg-id 26424.1183077245@sss.pgh.pa.us
Whole thread Raw
In response to Re: lazy vacuum sleeps with exclusive lock on table  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: lazy vacuum sleeps with exclusive lock on table  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-hackers
Alvaro Herrera <alvherre@commandprompt.com> writes:
> What I'm requesting here is that the sleep in count_nondeletable_pages()
> be removed and that change backpatched to 8.2 and 8.1.

Are you sure that that is, and always will be, the only sleep in that
part of the code path?

Seems like it might be better to adjust the cost_delay parameters after
we acquire exclusive lock.  I'm not sure dialing them all the way back
to zero is a good idea, but certainly we could make them more
aggressive.

>> Seems like VACUUM shouldn't try just once to get the lock.

> We don't know how many pages we can truncate until after we have
> acquired the exclusive lock and examined the pages in question, scanning
> backwards from the end of the table.

We could estimate this during the forward scan.  The backward scan is
still necessary to see if anyone has inserted tuples after we looked at
a page, but certainly a page that VACUUM failed to empty will still be
nonempty, so we can determine an upper bound on how much might be
truncatable.

However, that's an orthogonal concern and should probably be discussed
separately.
        regards, tom lane


pgsql-hackers by date:

Previous
From: ITAGAKI Takahiro
Date:
Subject: Re: lazy vacuum sleeps with exclusive lock on table
Next
From: Alvaro Herrera
Date:
Subject: Re: AutoVacuum Behaviour Question