Re: HOT for PostgreSQL 8.3

From: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org, Pavan Deolasee <pavan(dot)deolasee(at)enterprisedb(dot)com>, Nikhil S <nikhil(dot)sontakke(at)enterprisedb(dot)com>
Subject: Re: HOT for PostgreSQL 8.3
Date: 2007-02-09 13:39:55
Message-ID: 45CC79AB.2030203@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> ISTM we could fix that by extending the index VACUUM interface to
> include two concepts: aside from "remove these TIDs when you find them",
> there could be "replace these TIDs with those TIDs when you find them".
> This would allow pointer-swinging to one of the child tuples, after
> which the old root could be removed.

Implementing the "replace these TIDs" operation atomically would be
simple, except for the new bitmap index am. It should be possible there
as well, but if the old and new tid happen to be on a different bitmap
page, it requires some care to avoid deadlocks.

Also, we'd need more work mem for vacuum.

> This has got the same atomicity
> problem as for CREATE INDEX, because it's the same thing: you're
> de-HOT-ifying the child.

Not exactly. De-HOT-ifying, or chilling, a child means inserting new
index entries. But if we're just replacing the tids from the existing
index entries, it's ok if we crash after replacing some but not all of
them. The next vacuum would replace the rest of the pointers, and remove
the old root tuple.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Martijn van Oosterhout 2007-02-09 14:11:05 Re: Archive log compression keeping physical log available in the crash recovery
Previous Message Doug Knight 2007-02-09 13:16:14 Re: Database backup mechanism