Re: Improvement of procArray.xmin for VACUUM
От | Gregory Stark |
---|---|
Тема | Re: Improvement of procArray.xmin for VACUUM |
Дата | |
Msg-id | 87odmh2m3f.fsf@oxford.xeocode.com обсуждение исходный текст |
Ответ на | Re: Improvement of procArray.xmin for VACUUM (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-patches |
"Tom Lane" <tgl@sss.pgh.pa.us> writes: > Gregory Stark <stark@enterprisedb.com> writes: >> Well I think this would be the same infrastructure we would need to do >> the other discussed improvement to address pg_dump's impact. That >> would require us to publish the youngest xmax of the live >> snapshots. Vacuum could deduce that that xid cannot possibly see any >> transactions between the youngest extant xmax and the oldest >> in-progress transaction. > > ... and do what with the knowledge? Not remove tuples, because any such > tuples would be part of RECENTLY_DEAD update chains that that xact might > be following now or in the future. Well that just means it might require extra work, not that it would be impossible. Firstly, some tuples would not be part of a chain and could be cleaned up anyways. Others would be part of a HOT chain which might make it easier to clean them up. But even for tuples that are part of a chain there may be solutions. We could truncate the tuple to just the MVCC information so subsequent transactions can find the head. Or we might be able to go back and edit the forward link to skip the dead intermediate tuples (and somehow deal with the race conditions...) -- Gregory Stark EnterpriseDB http://www.enterprisedb.com
В списке pgsql-patches по дате отправления: