On 14.11.2010 00:29, Robert Haas wrote:
On Sat, Nov 13, 2010 at 12:13 PM, Tom Lane<t...@sss.pgh.pa.us> wrote:
Hannu Krosing<ha...@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, since page
pruning wouldn't know if there were index entries pointing at them.
But that seems like a pretty tiny penalty.
I'm not at all convinced that's a tiny penalty.
Me neither. It's a tiny penalty when you consider one update, but if you
repeatedly update the same tuple, you accumulate dead line pointers
until the next real vacuum runs. With HOT updates, you reach a steady
state where page pruning is all you need. Then again, if you're
repeatedly updating a row in a table with no indexes, presumably it's a
very small table or you would create an index on it. And frequently
autovacuuming a small index is quite cheap too.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
