X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 647FB528BB for ; Tue, 28 Jun 2005 12:28:12 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 53967-04 for ; Tue, 28 Jun 2005 15:28:03 +0000 (GMT) Received: from vms044pub.verizon.net (vms044pub.verizon.net [206.46.252.44]) by svr1.postgresql.org (Postfix) with ESMTP id 2894952835 for ; Tue, 28 Jun 2005 12:28:02 -0300 (ADT) Received: from osgiliath.mathom.us ([70.108.108.63]) by vms044.mailsrvcs.net (Sun Java System Messaging Server 6.2 HotFix 0.04 (built Dec 24 2004)) with ESMTPA id <0IIS002PIWAFG2S9@vms044.mailsrvcs.net> for pgsql-performance@postgresql.org; Tue, 28 Jun 2005 10:27:52 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by osgiliath.mathom.us (Postfix) with ESMTP id 02F14610196 for ; Tue, 28 Jun 2005 11:27:51 -0400 (EDT) Received: from osgiliath.mathom.us ([127.0.0.1]) by localhost (osgiliath [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 11778-03-10 for ; Tue, 28 Jun 2005 11:27:50 -0400 (EDT) Received: by osgiliath.mathom.us (Postfix, from userid 1000) id D490260014F; Tue, 28 Jun 2005 11:27:50 -0400 (EDT) Date: Tue, 28 Jun 2005 11:27:50 -0400 From: Michael Stone Subject: read block size To: pgsql-performance@postgresql.org Mail-Followup-To: pgsql-performance@postgresql.org Message-id: <20050628152750.GV9591@mathom.us> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-disposition: inline X-Pgp-Fingerprint: 53 FF 38 00 E7 DD 0A 9C 84 52 84 C5 EE DF 7C 88 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at mathom.us User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.036 tagged_above=0 required=5 tests=AWL, FORGED_RCVD_HELO X-Spam-Level: X-Archive-Number: 200506/562 X-Sequence-Number: 13199 Is it possible to tweak the size of a block that postgres tries to read when doing a sequential scan? It looks like it reads in fairly small blocks, and I'd expect a fairly significant boost in i/o performance when doing a large (multi-gig) sequential scan if larger blocks were used. Mike Stone