Tom Lane wrote:> "Pavan Deolasee" <pavan.deolasee@enterprisedb.com> writes:>> Any thoughts on the overall approach ?>>
Fragileand full of race conditions :-(.>
Yes, it looks a bit complex. But IMHO we can get around that.
Do you have any ideas in mind about doing that ?
> I thought from the beginning> that CREATE INDEX might be a showstopper for the whole HOT concept,> and it's starting
tolook like that's the case.
I remember you raised this concern very early, but I am hopeful
that we would be able to solve this. Would it be acceptable
to have a simple (though not the best) solution for this release
and then improve later on ? As I mentioned earlier, one option
is to CHILL the table, if required, holding AccessExclusive lock,
just like VACUUM FULL. I am assuming here that CREATE INDEX is
not such a common activity, isn't that true ?
> 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.
What if we only applied> HOT to primary-key indexes, so that there was certainly not more than> one index per table
thatthe property applies to?>
I think that will take away the ability to reuse HEAP_ONLY tuples
without vacuuming the heap and index.
Thanks,
Pavan
--
EnterpriseDB http://www.enterprisedb.com
