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

Re: Dead Space Map

From: Hannu Krosing <hannu(at)skype(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>,pgsql-hackers(at)postgresql(dot)org
Subject: Re: Dead Space Map
Date: 2006-02-28 08:04:00
Message-ID: 1141113840.3775.22.camel@localhost.localdomain (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Ühel kenal päeval, E, 2006-02-27 kell 15:05, kirjutas Tom Lane:
> Heikki Linnakangas <hlinnaka(at)iki(dot)fi> writes:
> > On Mon, 27 Feb 2006, Tom Lane wrote:
> >> This strikes me as a fairly bad idea, because it makes VACUUM dependent
> >> on correct functioning of user-written code --- consider a functional
> >> index involving a user-written function that was claimed to be immutable
> >> and is not.
> > If the user-defined function is broken, you're in more or less trouble 
> > anyway.
> Less.  A non-immutable function might result in lookup failures (not
> finding the row you need) but not in database corruption, which is what
> would ensue if VACUUM fails to remove an index tuple. 

Arguably the database is *already* broken once one has used a
non-immutable function in index ops.

"Failing to remove" is a condition that is easily detected, so one can
flag the operator class as lossy (RECHECK) and actually fix that

> Moreover, you haven't pointed to any strong reason to adopt this
> methodology.  It'd only be a win when vacuuming pretty small numbers
> of tuples, which is not the design center for VACUUM, and isn't likely
> to be the case in practice either if you're using autovacuum.  If you're
> removing say 1% of the tuples, you are likely to be hitting every index
> page to do it, meaning that the scan approach will be significantly
> *more* efficient than retail lookups.

One use-case would be keeping update-heavy databases healthy, by
ensuring that most updates will end up in the same page as originals.

That goal would be easier to achieve, if there were a process which
reclaims old tuples as fast as possible.


In response to


pgsql-hackers by date

Next:From: Hannu KrosingDate: 2006-02-28 08:12:24
Subject: Re: Dead Space Map
Previous:From: Hannu KrosingDate: 2006-02-28 07:52:24
Subject: Re: Dead Space Map

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