On Fri, 2007-03-16 at 12:40 -0400, Tom Lane wrote:
> "Pavan Deolasee" <pavan.deolasee@enterprisedb.com> 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
