Re: Automatic free space map filling - Mailing list pgsql-hackers

From Martijn van Oosterhout
Subject Re: Automatic free space map filling
Date
Msg-id 20060501183617.GB27150@svana.org
Whole thread Raw
In response to Re: Automatic free space map filling  ("Jim C. Nasby" <jnasby@pervasive.com>)
Responses Re: Automatic free space map filling  ("Dawid Kuroczko" <qnex42@gmail.com>)
List pgsql-hackers
On Mon, May 01, 2006 at 01:19:30PM -0500, Jim C. Nasby wrote:
> ISTM that tying this directly to maintenance_work_mem is a bit
> confusing, since the idea is to keep vacuum transaction duration down so
> that it isn't causing dead tuples to build up itself. It seems like it
> would be better to have vacuum start a fresh transaction after a certain
> number of tuples have died. But since there's no way to actually measure
> that without having row level stats turned on, maybe number of
> transactions or length of time would be good surrogates.

AIUI, vacuum starts a fresh cycle because it's accumulated a certain
number of dead tuples to clean up. Isn't that what you're asking for?
maintenance_work_mem is the limit on the amount of deleted tuple
information that can be stored (amongst other things I'm sure)...

> Since it sounds like we'd want the transaction to start only at the
> start of a clean cycle it could just check the limits at the start of
> each cycle. That would prevent it from wrapping the vacuum of each small
> table with a (rather pointless) new transaction.

Every table has to be in its own transaction since thats the duration
of the locks. Vacuum handling multiple tables in one transaction leaves
you open to deadlocks.

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Automatic free space map filling
Next
From: "Jonah H. Harris"
Date:
Subject: Re: InsertXLogFile in pg_resetxlog