Simon Riggs wrote:
On Thu, 2007-11-22 at 13:21 -0500, Tom Lane wrote:
Simon Riggs <[EMAIL PROTECTED]> writes:
Why isn't VACUUM optimised the same way HOT is?
It doesn't do the same things HOT does.
Thanks for the enlightenment :-)
Clearly much of the code in heap_page_prune_opt() differs, yet the test
for if (!PageIsPrunable(...)) could be repeated inside the main block
scan loop in lazy_scan_heap().
My thought-experiment:
- a long running transaction is in progress
- HOT cleans a block and then the block is not touched for a while, the
total of all uncleanable updates cause a VACUUM to be triggered, which
then scans the table, sees the block and scans the block again
because...
a) it could have checked !PageIsPrunable(), but didn't
b) it is important that it attempt to clean the block again for
reason...?
There might be dead tuples left over by aborted INSERTs, for example,
which don't set the Prunable-flag.
Even if we could use PageIsPrunable, it would be a bad thing from a
robustness point of view. If we ever failed to set the Prunable-flag on
a page for some reason, VACUUM would never remove the dead tuples.
Besides, I don't remember anyone complaining about VACUUM's CPU usage,
so it doesn't really matter.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
