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.
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.
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?
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
