Re: [HACKERS] Realtime VACUUM, was: performance of insert/delete/update

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Curtis Faith" <curtis(at)galtair(dot)com>
Cc: "Ron Johnson" <ron(dot)l(dot)johnson(at)cox(dot)net>, "PgSQL Performance ML" <pgsql-performance(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] Realtime VACUUM, was: performance of insert/delete/update
Date: 2002-11-27 03:13:51
Message-ID: 13413.1038366831@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance

"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

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2002-11-27 04:56:27 Interface update for 7.3
Previous Message Matthew T. O'Connor 2002-11-27 02:54:34 Auto Vacuum Daemon (again...)

Browse pgsql-performance by date

  From Date Subject
Next Message Nicolai Tufar 2002-11-27 14:02:22 Re: [HACKERS] Realtime VACUUM, was: performance of insert/delete/update
Previous Message typea 2002-11-27 02:40:38 Re: Full Text Index disk space requirements