From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Gregory Stark <stark(at)enterprisedb(dot)com> |
Cc: | "Jeff Davis" <pgsql(at)j-davis(dot)com>, "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>, "Patches" <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: Synchronized scans |
Date: | 2007-06-09 19:20:59 |
Message-ID: | 3029.1181416859@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> The vacuum-cost-limit issue may be sufficient reason to kill this idea;
>> not sure.
> We already have a much higher cost for blocks that cause i/o than
> blocks which don't. I think if we had zero cost for blocks which don't
> cause i/o it would basically work unless the sleep time was so large
> that the other scans managed to cycle through the entire ring in that
> time.
I'm unconvinced. That could perhaps work as long as the vacuum process
never did any I/O, ie was always a follower and never the leader of the
syncscan pack. But if lazy_heap_scan is faster than a regular seqscan,
as I suspect, then it'd frequently become the leader and have to do the
I/O. A few iterations of that will cause it to hit the vacuum cost
sleep, and that will make it fall behind the pack (and probably out of
sync entirely, unless the sleep is really short).
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2007-06-09 20:55:55 | Re: Regression tests |
Previous Message | Gregory Stark | 2007-06-09 19:12:07 | Re: Synchronized scans |