Re: Autovacuum and OldestXmin
От | Heikki Linnakangas |
---|---|
Тема | Re: Autovacuum and OldestXmin |
Дата | |
Msg-id | 4745D22E.6050505@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Autovacuum and OldestXmin (Simon Riggs <simon@2ndquadrant.com>) |
Ответы |
Re: Autovacuum and OldestXmin
|
Список | pgsql-hackers |
Simon Riggs wrote: > On Thu, 2007-11-22 at 13:21 -0500, Tom Lane wrote: >> Simon Riggs <simon@2ndquadrant.com> 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
В списке pgsql-hackers по дате отправления: