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
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-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

Browse pgsql-hackers by date

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

Browse pgsql-patches by date

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