X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org
Received: from localhost (av.hub.org [200.46.204.144])
	by postgresql.org (Postfix) with ESMTP id DD68E9DCADF
	for <pgsql-hackers-postgresql.org@localhost.postgresql.org>;
	Tue, 29 Nov 2005 11:06:33 -0400 (AST)
Received: from postgresql.org ([200.46.204.71])
	by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
	with ESMTP id 34336-02
	for <pgsql-hackers-postgresql.org@localhost.postgresql.org>;
	Tue, 29 Nov 2005 11:06:32 -0400 (AST)
X-Greylist: from auto-whitelisted by SQLgrey-
Received: from svana.org (svana.org [203.20.62.76])
	by postgresql.org (Postfix) with ESMTP id EBB939DCC87
	for <pgsql-hackers@postgresql.org>;
	Tue, 29 Nov 2005 11:06:25 -0400 (AST)
Received: from kleptog by svana.org with local (Exim 3.35 #1 (Debian))
	id 1Eh73j-0000vB-00; Wed, 30 Nov 2005 02:06:19 +1100
Date: Tue, 29 Nov 2005 16:06:18 +0100
From: Martijn van Oosterhout <kleptog@svana.org>
To: "Pollard, Mike" <mpollard@cincom.com>
Cc: Qingqing Zhou <zhouqq@cs.toronto.edu>, pgsql-hackers@postgresql.org
Subject: Re: ice-broker scan thread
Message-ID: <20051129150617.GE31333@svana.org>
Reply-To: Martijn van Oosterhout <kleptog@svana.org>
References: <6418CC03D0FB1943A464E1FEFB3ED46B01B220E7@im01.cincom.com>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="EgVrEAR5UttbsTXg"
Content-Disposition: inline
In-Reply-To: <6418CC03D0FB1943A464E1FEFB3ED46B01B220E7@im01.cincom.com>
User-Agent: Mutt/1.3.28i
X-PGP-Key-ID: Length=1024; ID=0x0DC67BE6
X-PGP-Key-Fingerprint: 295F A899 A81A 156D B522  48A7 6394 F08A 0DC6 7BE6
X-PGP-Key-URL: <http://svana.org/kleptog/0DC67BE6.pgp.asc>
X-Virus-Scanned: by amavisd-new at hub.org
X-Spam-Status: No, score=0 required=5 tests=[AWL=0.000]
X-Spam-Score: 0
X-Spam-Level: 
X-Archive-Number: 200511/1476
X-Sequence-Number: 76758


--EgVrEAR5UttbsTXg
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Nov 29, 2005 at 09:45:30AM -0500, Pollard, Mike wrote:
> 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

<snip>

> so above, the user threads is starting low in the table and working
> high; the readahead threads are starting higher (but not at the end of
> the table), and working low. =20

Ok, this may be a really dumb question, but doesn't this rely on the
fact that the table is smaller than the amount of buffers? If the table
is large most of your data will be tossed out again by later data
before it's been used by the backend.

Have a nice day,
--=20
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

--EgVrEAR5UttbsTXg
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQFDjG5oIB7bNG8LQkwRAuHhAKCOJX4DBYqDJON83okgMNJtkLthAgCeNVV4
c4jw5ItFqiBYYZOUrqFHNq8=
=V9K+
-----END PGP SIGNATURE-----

--EgVrEAR5UttbsTXg--