From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> |
Cc: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Jeff Davis" <pgsql(at)j-davis(dot)com>, "Patches" <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: Synchronized scans |
Date: | 2007-06-10 20:14:44 |
Message-ID: | 877iqbva6j.fsf@oxford.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
"Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> writes:
> 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.
I think we could probably arrange for vacuum to synchronize. If there's one
sequential scan running we have to imagine there are others coming along soon
too. so if we become desynchronized we'll just coerce the next one to start
where we want and follow it for a while.
However I have a another worry. Even if we did manage to get vacuum
synchronizing well what would it do to the sequential scan performance.
Instead of zipping along reading clean blocks into its small ring buffer and
discarding them when it's done it'll suddenly find many of its blocks dirty
when it goes to reuse them. Effectively we'll have just reinvented the problem
we had with vacuum previously albeit in a way which only hits sequential scans
particularly hard.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-06-11 01:39:58 | Re: Synchronized scans |
Previous Message | Heikki Linnakangas | 2007-06-10 20:02:50 | Re: Synchronized scans |