Re: CREATE INDEX and HOT (was Question:pg_classattributes and race conditions ?)

From: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
To: Hannu Krosing <hannu(at)skype(dot)net>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Pavan Deolasee <pavan(dot)deolasee(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: CREATE INDEX and HOT (was Question:pg_classattributes and race conditions ?)
Date: 2007-03-19 14:49:49
Message-ID: 45FEA30D.6040305@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hannu Krosing wrote:
> Ühel kenal päeval, E, 2007-03-19 kell 12:05, kirjutas Simon Riggs:
>> On Mon, 2007-03-19 at 10:51 +0000, Heikki Linnakangas wrote:
>>> Pavan Deolasee wrote:
>>>> We've already used three of those, two for tracking HEAP_ONLY
>>>> and HOT_UPDATED tuples and one for tracking fragmented tuple.
>>> HEAP_ONLY_TUPLE would go away in favor of the per-index bits. So we have
>>> bits available for three indexes.
>
> But you probably have to do some kind of SUPERFULL VACUUM if you want to
> DROP and CREATE the third index. You will probably have to touch all
> tuples, regardless of weather they are live or not, or if will be moved
> or not, just to kclean ot bits for the just-deleted index.

DROP INDEX wouldn't do anything extra. CREATE INDEX would have to clear
the bit assigned to the new index, which would mean dirtying every heap
page in the worst case. As a further optimization, CREATE INDEX could
skip index inserts for HOT-updated tuples, if the key for new index
wasn't changed, and leave the flag set.

Vacuum isn't needed.

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2007-03-19 15:13:55 getTypeIOParam is wrong for domains over array types?
Previous Message Teodor Sigaev 2007-03-19 14:36:23 Re: Indexam interface proposal