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

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
      subscribe-nomail command to [EMAIL PROTECTED] so that your
      message can get through to the mailing list cleanly

Reply via email to