Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-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

pgsql-performance by date

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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group