User-Agent: Microsoft-Entourage/11.2.5.060620
Date: Mon, 25 Sep 2006 07:23:58 -0700
Subject: Re: Large tables (was: RAID 0 not as fast as
From: "Luke Lonergan" <llonergan@greenplum.com>
To: "Jim C. Nasby" <jim@nasby.net>
cc: mark@mark.mielke.cc, "Guy Thornley" <guy@esphion.com>,
	"Markus Schaber" <schabi@logix-tt.com>, pgsql-performance@postgresql.org
Message-ID: <C13D348E.283A%llonergan@greenplum.com>
Thread-Topic: [PERFORM] Large tables (was: RAID 0 not as fast as
Thread-Index: Acbgrj0Pe2TVPUyhEdu8TQAWy4o9DA==
In-Reply-To: <20060922140113.GW28987@nasby.net>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=us-ascii
Content-Transfer-Encoding: 7bit

Jim,

On 9/22/06 7:01 AM, "Jim C. Nasby" <jim@nasby.net> wrote:

> There's been talk of adding code that would have a seqscan detect if
> another seqscan is happening on the table at the same time, and if it
> is, to start it's seqscan wherever the other seqscan is currently
> running. That would probably ensure that we weren't reading from the
> table in 2 different places, even if we weren't caching.

Right, aka "SyncScan"

The optimization you point out that we miss when bypassing cache is a pretty
unlikely event in real world apps, though it makes poorly designed
benchmarks go really fast.  It's much more likely that the second seqscan
will start after the block cache is exhausted, which will cause actuator
thrashing (depending on the readahead that the OS uses).  SyncScan fixes
that.

- Luke