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



EnterpriseDB        http://www.enterprisedb.com

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Reply via email to