Hannu Krosing <hannu@2ndQuadrant.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