Re: Synchronized scans

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

In response to

Browse pgsql-patches by date

  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