Re: Fwd: Clarification about HOT

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Gokulakannan Somasundaram" <gokul007(at)gmail(dot)com>
Cc: "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>, "PostgreSQL-development Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Fwd: Clarification about HOT
Date: 2007-11-05 14:34:54
Message-ID: 19017.1194273294@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Gokulakannan Somasundaram" <gokul007(at)gmail(dot)com> writes:
> Currently, during Vacuum, we goto the Index and mark it as dead and
> reclaim the space. For doing this, we are acquiring a Super-Exclusive lock.
> After this implementation, we would update the index tuple instead of
> marking it for cleanup. What can be foreseen as a locking overhead here?

There are three operations involved: marking the child tuple not-HOT,
updating the index entry(s), and removing the parent tuple. I doubt you
can do them safely as independent atomic operations; I think you'll need
to have more than one page locked at a time. The locking problem also
applies to trying to collapse out a dead HOT tuple that's in the middle
of the chain: if it's the end of a cross-page link then you need two
pages super-exclusive-locked in order to do that.

There's also the little problem that a redirect line pointer doesn't
have room for a cross-page link, and the big problem that having to
chase across multiple pages for an index lookup would almost certainly
negate any performance gains you might get. (In particular it'd
completely destroy locality of access for bitmap indexscans...)

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2007-11-05 14:38:17 Re: Visibility map thoughts
Previous Message Gokulakannan Somasundaram 2007-11-05 14:34:34 Re: Fwd: Clarification about HOT