pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Luke Lonergan <llonergan@greenplum.com>
To: Jim C. Nasby <jim@nasby.net>
Cc: mark@mark.mielke.cc, "Guy Thornley" <guy@esphion.com>
Cc: Markus Schaber <schabi@logix-tt.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Large tables (was: RAID 0 not as fast as
Date: Mon, 25 Sep 2006 07:23:58 -0700
Message-ID: <C13D348E.283A%llonergan@greenplum.com> (raw)
In-Reply-To: <20060922140113.GW28987@nasby.net>

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





view thread (24+ messages)

Message-ID: <C13D348E.283A%llonergan@greenplum.com>
Permalink:  ../C13D348E.283A%25llonergan@greenplum.com/
Also on:    postgresql.org/message-id/C13D348E.283A%llonergan@greenplum.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: llonergan@greenplum.com, jim@nasby.net, guy@esphion.com, schabi@logix-tt.com
  Subject: Re: Large tables (was: RAID 0 not as fast as
  In-Reply-To: <C13D348E.283A%llonergan@greenplum.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox