On Sat, 2010-11-13 at 12:13 -0500, Tom Lane wrote:
> Hannu Krosing <hannu@2ndQuadrant.com> writes:
> > On Sat, 2010-11-13 at 10:51 -0500, Tom Lane wrote:
> >> If a table has no indexes, we will always decide that any same-page
> >> update operation is a HOT update, since obviously it isn't modifying
> >> any indexed columns. But is there any benefit to doing so?
>
> > If we do the in-page "mini vacuum" even without HOT, then there should
> > be no benefit from index-less HOT updates.
>
> 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 ?
> since page
> pruning wouldn't know if there were index entries pointing at them.
> But that seems like a pretty tiny penalty.
>
> regards, tom lane
--
-------
Hannu Krosing
PostgreSQL Infinite Scalability and Performance Consultant
PG Admin Book: http://www.2ndQuadrant.com/books/
