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
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 |