Re: Synchronized scans
От | Heikki Linnakangas |
---|---|
Тема | Re: Synchronized scans |
Дата | |
Msg-id | 466C58EA.7020901@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Synchronized scans (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Synchronized scans
|
Список | pgsql-patches |
Tom Lane wrote: > Jeff Davis <pgsql@j-davis.com> writes: >> * Just adding in the syncscan to scan_heap and lazy_scan_heap seems >> very easy at first thought. Are there any complications that I'm >> missing? > > I believe there are assumptions buried in both full and lazy vacuum that > blocks are scanned in increasing order. Not sure how hard that would be > to fix or work around. The only one I can specifically recall in lazy > vacuum is that we assume the list of deletable TIDs is sorted a priori. > Possibly you could deal with that by forcing an index-vacuum pass at the > instant where the scan would wrap around, so that the list could be > cleared before putting any lower-numbered blocks into it. In this case, we're still scanning the table in increasing order, the zero-point is just shifted. We can still do a binary search if we do it in a whacky module-arithmetic fashion. I believe TID list ordering is the only reason why we need to scan in order. I don't think sync-scanning vacuum is worth pursuing, though, because of the other issues: index scans, vacuum cost accounting, and the fact that the 2nd pass would be harder to synchronize. There's a lot of other interesting ideas for vacuum that are more generally applicable. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-patches по дате отправления: