Re: Plans for solving the VACUUM problem - Mailing list pgsql-hackers

From Vadim Mikheev
Subject Re: Plans for solving the VACUUM problem
Date
Msg-id 004301c0e1a1$d1e7fd80$4879583f@sectorbase.com
Whole thread Raw
In response to Re: Plans for solving the VACUUM problem  (The Hermit Hacker <scrappy@hub.org>)
Responses Re: Plans for solving the VACUUM problem  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> If its an "experiment", shouldn't it be done outside of the main source
> tree, with adequate testing in a high load situation, with a patch
> released to the community for further testing/comments, before it is added
> to the source tree?  From reading Vadim's comment above (re:
> pre-Postgres95), this daemonized approach would cause a high I/O load on
> the server in a situation where there are *alot* of UPDATE/DELETEs
> happening to the database, which should be easily recreatable, no?  Or,
> Vadim, am I misundertanding?

It probably will not cause more IO than vacuum does right now.
But unfortunately it will not reduce that IO. Cleanup work will be spreaded
in time and users will not experience long lockouts but average impact
on overall system throughput will be same (or maybe higher).
My point is that we'll need in dynamic cleanup anyway and UNDO is
what should be implemented for dynamic cleanup of aborted changes.
Plus UNDO gives us natural implementation of savepoints and some
abilities in transaction IDs management, which we may use or not
(though, 4. - pg_log size management - is really good thing).

Vadim




pgsql-hackers by date:

Previous
From: "Vadim Mikheev"
Date:
Subject: Re: Plans for solving the VACUUM problem
Next
From: "Vadim Mikheev"
Date:
Subject: Re: Plans for solving the VACUUM problem