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...? Seems like the thought experiment could occur frequently. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.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
