Re: Fwd: Clarification about HOT

From: "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com>
To: "Gokulakannan Somasundaram" <gokul007(at)gmail(dot)com>
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "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:19:51
Message-ID: 2e78013d0711050619w35e12229x3ef651593416cfaa@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Nov 5, 2007 7:37 PM, Gokulakannan Somasundaram <gokul007(at)gmail(dot)com>
wrote:

> Tom,
> Let me try to understand your statement.
>
> What extra multi-page operations are we doing?
> 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?
>
>
>
Its not just about vacuuming. You need to worry about locking during the
HOT-fetches as well as chain pruning. There could be tricky corner cases
between index/seq scans and pruning. And don't forget CREATE INDEX
which would become even more challenging if you have HOT chains
spanning multiple pages.

This is not to discourage you from trying to improve HOT. But
once-upon-a-time
we had this multi-page HOT (it was called Heap-Overflow-Tuple) and I can
tell you: it was really complex.

Thanks,
Pavan

--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2007-11-05 14:23:24 Re: pg_ctl configurable timeout
Previous Message Tom Lane 2007-11-05 14:11:17 pgsql: Add a note about another issue that needs to be considered before