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

Re: VACUUM Improvements - WIP Patch

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>
Cc: pgsql-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: VACUUM Improvements - WIP Patch
Date: 2008-07-01 07:41:34
Message-ID: 1214898094.3845.537.camel@ebony.site (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
On Tue, 2008-06-10 at 11:02 +0530, Pavan Deolasee wrote:

> In most of the cases where the old transactions quickly go away, and
> for large tables, the second scan will be very limited. In the worst
> case, we might incur the overhead of conditional waits without any
> success.

Looks good.

> - An additional boolean pg_class attribute (relvac_inprogress) is used
> to track the status of vacuum on a relation. If the attribute is true,
> either vacuum is in progress on the relation or the last vacuum did
> not complete successfully.
> 
> When VACUUM starts, it sets relvac_inprogress to true.

What happens if the last VACUUM crashed? Any negative effects? If so,
should autovac be triggered again soon to complete the failed VACUUM?

> - We can potentially update FSM at the end of first pass. This is not
> a significant issue if the second scan is very limited. But if we do
> this, we need to handle the truncate case properly.

Not sure why would we do that? What would that give? To do that you'd
need to completely redesign FSM since it assumes only one update would
take place.

> - As the patch stands, we check of old transactions at every block
> iteration. This might not be acceptable for the cases where there are
> long running transactions. We probably need some exponential gap here.

I would make vacuum_delay_point() return bool rather than void, then you
can do the check each time we do the delay by saying:

if (vacuum_delay_point())
{

Need to change VacuumCostActive so it is always active during a VACUUM,
so we do accounting even when vacuum wait is zero.


-- 
 Simon Riggs           www.2ndQuadrant.com
 PostgreSQL Training, Services and Support


In response to

pgsql-hackers by date

Next:From: Richard HuxtonDate: 2008-07-01 07:45:44
Subject: Re: Does anything dump per-database config settings? (was Re: ALTER DATABASE vs pg_dump)
Previous:From: Robert TreatDate: 2008-07-01 05:08:26
Subject: Re: GIT repo broken

pgsql-patches by date

Next:From: Simon RiggsDate: 2008-07-01 08:39:08
Subject: Re: [HACKERS] odd output in restore mode
Previous:From: Bruce MomjianDate: 2008-07-01 00:09:08
Subject: Re: Patch to change psql default banner v6

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