Re: HOT updates in index-less tables

Hannu Krosing <hannu(at)2ndQuadrant(dot)com> writes:
> On Sat, 2010-11-13 at 12:13 -0500, Tom Lane wrote:
>> AFAICS we do: heap_update marks the page as prunable whether it's a HOT
>> update or not. The only difference between treating the update as HOT vs
>> not-HOT is that if there was more than one HOT update, the intermediate
>> tuples could be completely reclaimed by page pruning (ie, their line
>> pointers go away too). With not-HOT updates, the intermediate line
>> pointers would have to remain in DEAD state until vacuum,

> How hard would it be to make the pruning logic be aware of there being
> no indexes and thus no possibility of index entries pointing at any
> tuple ?

I think it's problematic, because heap_page_prune can be executed with
only AccessShareLock on the table, which means there's a race condition
against concurrent CREATE INDEX. You could look at relhasindex easily
enough, but that doesn't prove there's not a CREATE INDEX in progress.

regards, tom lane