From: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Jeff Davis <pgsql(at)j-davis(dot)com>, Patches <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: Synchronized scans |
Date: | 2007-06-10 20:02:50 |
Message-ID: | 466C58EA.7020901@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Tom Lane wrote:
> Jeff Davis <pgsql(at)j-davis(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Gregory Stark | 2007-06-10 20:14:44 | Re: Synchronized scans |
Previous Message | Heikki Linnakangas | 2007-06-10 19:49:24 | Re: Controlling Load Distributed Checkpoints |