Re: Proposal: Log inability to lock pages during vacuum - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Proposal: Log inability to lock pages during vacuum
Date
Msg-id CA+U5nML=haHBeTLimwPYuX+fB3vGuWQYS7PqfEcS_UeGcT4zNw@mail.gmail.com
Whole thread Raw
In response to Re: Proposal: Log inability to lock pages during vacuum  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
List pgsql-hackers
On 9 December 2014 at 06:28, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
> On 12/7/14, 6:16 PM, Simon Riggs wrote:

>> What I'm more interested in is what you plan to do with the
>> information once we get it?
>>
>> The assumption that skipping blocks is something bad is strange. I
>> added it because VACUUM could and did regularly hang on busy tables,
>> which resulted in bloat because other blocks that needed cleaning
>> didn't get any attention.
>>
>> Which is better, spend time obsessively trying to vacuum particular
>> blocks, or to spend the time on other blocks that are in need of
>> cleaning and are available to be cleaned?
>>
>> Which is better, have autovacuum or system wide vacuum progress on to
>> other tables that need cleaning, or spend lots of effort retrying?
>>
>> How do we know what is the best next action?
>>
>> I'd really want to see some analysis of those things before we spend
>> even more cycles on this.
>
>
> That's the entire point of logging this information. There is an underlying
> assumption that we won't actually skip many pages, but there's no data to
> back that up, nor is there currently any way to get that data.

There is no such underlying assumption. You assumed there was one, but
there isn't one.

All I can say for certain is that waiting on a lock for long periods
was literally a waste of time. Now it no longer wastes time, it gets
on with vacuuming the pages it can.

-- Simon Riggs                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Compression of full-page-writes
Next
From: Josh Berkus
Date:
Subject: Re: On partitioning