Re: Automatic free space map filling

From: Christopher Browne <cbbrowne(at)acm(dot)org>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Automatic free space map filling
Date: 2006-03-02 13:33:46
Message-ID: 87ek1lq8cl.fsf@wolfe.cbbrowne.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Centuries ago, Nostradamus foresaw when tgl(at)sss(dot)pgh(dot)pa(dot)us (Tom Lane) would write:
> I thought we had sufficiently destroyed that "reuse a tuple" meme
> yesterday. You can't do that: there are too many aspects of the system
> design that are predicated on the assumption that dead tuples do not
> come back to life.

This discussion needs to come up again in October when the zombie
movies come out :-).

> That's the other problem: it's not apparent why pushing work from
> vacuum back into foreground processing is a good idea. Especially
> not why retail vacuuming of individual tuples will be better than
> wholesale.

What is unclear to me in the discussion is whether or not this is
invalidating the item on the TODO list...

-------------------
Create a bitmap of pages that need vacuuming

Instead of sequentially scanning the entire table, have the background
writer or some other process record pages that have expired rows, then
VACUUM can look at just those pages rather than the entire table. In
the event of a system crash, the bitmap would probably be
invalidated. One complexity is that index entries still have to be
vacuumed, and doing this without an index scan (by using the heap
values to find the index entry) might be slow and unreliable,
especially for user-defined index functions.
-------------------

It strikes me as a non-starter to draw vacuum work directly into the
foreground; there is a *clear* loss in that the death of the tuple
can't actually take place at that point, due to MVCC and the fact that
it is likely that other transactions will be present, keeping the
tuple from being destroyed.

But it would *seem* attractive to do what is in the TODO, above.
Alas, the user defined index functions make cleanout of indexes much
more troublesome :-(. But what's in the TODO is still "wholesale,"
albeit involving more targetted selling than the usual Kirby VACUUM
:-).
--
select 'cbbrowne' || '@' || 'gmail.com';
http://linuxdatabases.info/info/rdbms.html
Rules of the Evil Overlord #140. "I will instruct my guards when
checking a cell that appears empty to look for the chamber pot. If the
chamber pot is still there, then the prisoner has escaped and they may
enter and search for clues. If the chamber pot is not there, then
either the prisoner is perched above the lintel waiting to strike them
with it or else he decided to take it as a souvenir (in which case he
is obviously deeply disturbed and poses no threat). Either way,
there's no point in entering." <http://www.eviloverlord.com/>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2006-03-02 13:43:23 Re: ACCESS EXCLUSIVE LOCK
Previous Message Oleg Bartunov 2006-03-02 12:29:32 Re: PostgreSQL Anniversary Summit, Call for Contributions