MIME-Version: 1.0
User-Agent: Microsoft-Entourage/11.2.1.051004
In-Reply-To: <1133285745.1039.1.camel@toonses.gghcwest.com>
Content-class: urn:content-classes:message
Subject: Re: ice-broker scan thread
Date: Tue, 29 Nov 2005 18:42:27 -0500
Message-ID: <BFB22763.14A58%llonergan@greenplum.com>
Thread-Topic: [HACKERS] ice-broker scan thread
Thread-Index: AcX1DpeNYGIoyYznT8WtGGBZb+q72wAL/aCi
From: "Luke Lonergan" <LLonergan@greenplum.com>
To: "Jeffrey W. Baker" <jwbaker@acm.org>, "Pollard,
 Mike" <mpollard@cincom.com>
cc: "Qingqing Zhou" <zhouqq@cs.toronto.edu>,
	pgsql-hackers@postgresql.org
Content-Type: text/plain;
 charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Jeff,


On 11/29/05 9:35 AM, "Jeffrey W. Baker" <jwbaker@acm.org> wrote:

> On Tue, 2005-11-29 at 09:45 -0500, Pollard, Mike wrote:
>=20
>> Anyway, what I did was the following.  When doing a sequential scan, =
we
>> were starting at the beginning of the table and scanning forward.  If =
I
>> threw up some threads to read ahead, then my user thread and my read
>> ahead threads would thrash on trying to lock the buffer slots.  So, I
>> had the read ahead threads start at some distance into the table, and
>> work toward the beginning.
>=20
> I believe this is commonly called a synchronous scan.

I think sync scan refers to the use of a scanner shared among concurrent
queries, where they can join a scan in progress from it's current =
location.

It sounds like the logic could be shared.  Sync scan (as I've described
above) is another important optimization we'd like to see.

- Luke