Re: CREATE INDEX and HOT (was Question:pg_classattributes and race conditions ?) - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: CREATE INDEX and HOT (was Question:pg_classattributes and race conditions ?)
Date
Msg-id 45FEA30D.6040305@enterprisedb.com
Whole thread Raw
In response to Re: CREATE INDEX and HOT (was Question: pg_classattributes and race conditions ?)  (Hannu Krosing <hannu@skype.net>)
List 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


pgsql-hackers by date:

Previous
From: Teodor Sigaev
Date:
Subject: Re: Indexam interface proposal
Next
From: Tom Lane
Date:
Subject: getTypeIOParam is wrong for domains over array types?