On Fri, 2007-03-16 at 12:40 -0400, Tom Lane wrote: > "Pavan Deolasee" <[EMAIL PROTECTED]> writes: > > Any thoughts on the overall approach ? > > Fragile and full of race conditions :-(. I thought from the beginning > that CREATE INDEX might be a showstopper for the whole HOT concept, > and it's starting to look like that's the case.
Seems like we can fix all but some strange CREATE INDEX use cases. Since we have CREATE INDEX CONCURRENTLY, seems like HOT is a showstopper for the whole CREATE INDEX concept. > I think what we need to get away from is the assumption that HOT-ness > for one index is the same as HOT-ness for all. Sounds interesting. I'd not considered that before. > What if we only applied > HOT to primary-key indexes, so that there was certainly not more than > one index per table that the property applies to? On its own, I don't think this is a sufficiently wide use-case. Perhaps we should do this PLUS make HOT-semantics optional for each additional index. i.e. HOT is always enforced on primary indexes and optionally on other indexes (but not by default). If you accept the HOT option on an index, you then accept the additional issues surrounding chilling tuples. Bear in mind that there aren't any at all if you use CREATE INDEX CONCURRENTLY and many other cases. -- Simon Riggs 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
