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
headerand track HOT-ness of different indexes.>> The idea looks good but had a downside of increasing tuple>> header
andcomplexity.>> 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.
Domultiple heap-scan passes> 4. Wait longer in CREATE INDEX CONCURRENTLY> 5. Wait in CREATE INDEX, like we do in CREATE
INDEXCONCURRENTLY> 6. Lock the table exclusively> 7. Disallow multiple CREATE INDEXes at the same time.>> I've lost
trackof 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