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

Heikki Linnakangas wrote:
> Pavan Deolasee wrote:
>> 2. Heikki suggested an approach where we add a byte
>> to tuple header and track HOT-ness of different indexes.
>> The idea looks good but had a downside of increasing tuple
>> header and complexity.
>
> We would only need the extra byte in HOT-updated tuples.
Alternatively, we could use the bits we have free in infomask2. There's
currently 5 bits free, using just 2 or 3 of those would get us quite
far. Or just one, which would be the Tom's suggestion of only using HOT
for tables with a single index.
>

We've already used three of those, two for tracking HEAP_ONLY
and HOT_UPDATED tuples and one for tracking fragmented tuple.
Doing it for just one index seems too restrictive. Are we ok
with adding another byte to the tuple header ?

> Complexity is in the eye of the beholder. Chilling existing tuples
isn't exactly trivial either, and neither is getting all the locking and
waiting needed in the other proposals correct.
>

I agree. I am just worried about the short term and long
term solution. Your proposal is certainly the better of
all as it also gives us the ability to restrict bloats
on a index whose key does not change during UPDATE.

I would like to do something which is acceptable and is
also feasible to complete by feature freeze. Do you want
to give a shot to this approach while I try to build
the ALTER TABLE and CHILL utilities ?

> The simplicity of the other proposals depend a lot on what kind of
restrictions and changes to current semantics of CREATE INDEX
[CONCURRENTLY] we accept. Which of the following restrictions are we OK
with, if a table has HOT-updated tuples:
>
> 1. Throw an error
> 2. Require a vacuum after crash during CREATE INDEX
> 3. Do multiple heap-scan passes
> 4. Wait longer in CREATE INDEX CONCURRENTLY
> 5. Wait in CREATE INDEX, like we do in CREATE INDEX CONCURRENTLY
> 6. Lock the table exclusively
> 7. Disallow multiple CREATE INDEXes at the same time.
>
> I've lost track of which proposals lead to which restrictions. Maybe
we should look at the restrictions first, and judge which ones are
acceptable and which ones are not?
>

This is a good summary. With the assumption that creating
index is not very frequent operation, I would live with
1, 2, 3 and 4. But frankly I'm least knowledgable in this
regard and would rely on others to decide.

Thanks,
Pavan

--

EnterpriseDB http://www.enterprisedb.com