Re: [PERFORM] Realtime VACUUM, was: performance of insert/delete/update - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PERFORM] Realtime VACUUM, was: performance of insert/delete/update
Date
Msg-id 13413.1038366831@sss.pgh.pa.us
Whole thread Raw
In response to [PERFORM] Realtime VACUUM, was: performance of insert/delete/update  ("Curtis Faith" <curtis@galtair.com>)
List pgsql-hackers
"Curtis Faith" <curtis@galtair.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

pgsql-hackers by date:

Previous
From: "Matthew T. O'Connor"
Date:
Subject: Auto Vacuum Daemon (again...)
Next
From: Bruce Momjian
Date:
Subject: Interface update for 7.3