"Curtis Faith" <curtis(at)galtair(dot)com> writes:
> tom lane wrote:
>> Sure, it's just shuffling the housekeeping work from one place to
>> another. The thing that I like about Postgres' approach is that we
>> put the housekeeping in a background task (VACUUM) rather than in the
>> critical path of foreground transaction commit.
> Couldn't we reuse tuple and index space as soon as there are no transactions
> that depend on the old tuple or index values. I have imagined that this was
> always part of the long-term master plan.
> Couldn't we keep a list of dead tuples in shared memory and look in the list
> first when deciding where to place new values for inserts or updates so we
> don't have to rely on VACUUM (even a background one)?
ISTM that either of these ideas would lead to pushing VACUUM overhead
into the foreground transactions, which is exactly what we don't want to
do. Keep in mind also that shared memory is finite ... *very* finite.
It's bad enough trying to keep per-page status in there (cf FSM) ---
per-tuple status is right out.
I agree that automatic background VACUUMing would go a long way towards
reducing operational problems.
regards, tom lane
In response to
pgsql-performance by date
|Next:||From: Nicolai Tufar||Date: 2002-11-27 14:02:22|
|Subject: Re: [HACKERS] Realtime VACUUM, was: performance of insert/delete/update|
|Previous:||From: typea||Date: 2002-11-27 02:40:38|
|Subject: Re: Full Text Index disk space requirements|
pgsql-hackers by date
|Next:||From: Bruce Momjian||Date: 2002-11-27 04:56:27|
|Subject: Interface update for 7.3|
|Previous:||From: Matthew T. O'Connor||Date: 2002-11-27 02:54:34|
|Subject: Auto Vacuum Daemon (again...)|