Received: from localhost (maia-2.hub.org [200.46.204.187]) by postgresql.org (Postfix) with ESMTP id 65F879FA4F0 for ; Mon, 30 Jul 2007 03:54:18 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.187]) (amavisd-maia, port 10024) with ESMTP id 31398-02 for ; Mon, 30 Jul 2007 03:54:13 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from noel.decibel.org (noel.decibel.org [67.100.216.10]) by postgresql.org (Postfix) with ESMTP id 0B5F49FA4C5 for ; Mon, 30 Jul 2007 03:54:14 -0300 (ADT) Received: by noel.decibel.org (Postfix, from userid 1001) id E4FA35644A; Mon, 30 Jul 2007 01:54:13 -0500 (CDT) Received: (hashcash-sendmail, from uid 1001); Mon, 30 Jul 2007 01:54:12 -0500 Resent-From: decibel@decibel.org Resent-Date: Mon, 30 Jul 2007 01:54:12 -0500 Resent-Message-ID: <20070730065412.GT25704@decibel.org> Resent-To: pgsql-performance@postgresql.org Date: Mon, 30 Jul 2007 01:52:41 -0500 From: Decibel! To: Craig James Cc: pgsql-perform@postgresql.org Subject: Re: RES: RES: select on 1milion register = 6s Message-ID: <20070730065241.GR25704@decibel.org> References: <20070729163536.GM25704@nasby.net> <005b01c7d1ff$b96ea3d0$e900a8c0@brunolaptop> <20070730012926.GP25704@nasby.net> <46AD6B34.8090200@emolecules.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GlnCQLZWzqLRJED8" Content-Disposition: inline In-Reply-To: <46AD6B34.8090200@emolecules.com> X-Operating-System: FreeBSD 6.1-RELEASE-p10 amd64 X-Distributed: Join the Effort! http://www.distributed.net User-Agent: Mutt/1.5.13 (2006-08-11) X-Hashcash: 1:20:070730:pgsql-performance@postgresql.org::a604c7/Wxcopm9gz:00000 0000000000000000000000001vEx X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200707/416 X-Sequence-Number: 26100 --GlnCQLZWzqLRJED8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Please reply-all so others can learn and contribute. On Sun, Jul 29, 2007 at 09:38:12PM -0700, Craig James wrote: > Decibel! wrote: > >It's unlikely that it's going to be faster to index scan 2.3M rows than > >to sequential scan them. Try setting enable_seqscan=3Dfalse and see if it > >is or not. >=20 > Out of curiosity ... Doesn't that depend on the table? Are all of the da= ta=20 > for one row stored contiguously, or are the data stored column-wise? If= =20 > it's the former, and the table has hundreds of columns, or a few columns= =20 > with large text strings, then wouldn't the time for a sequential scan=20 > depend not on the number of rows, but rather the total amount of data? Yes, the time for a seqscan is mostly dependent on table size and not the number of rows. But the number of rows plays a very large role in the cost of an indexscan. --=20 Decibel!, aka Jim C. Nasby, Database Architect decibel@decibel.org=20 Give your computer some brain candy! www.distributed.net Team #1828 --GlnCQLZWzqLRJED8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.3 (FreeBSD) iD8DBQFGrYq5dO30qud8SkgRAmQAAKDcXEI1nuFwUMC8CfGfNseV+TID5QCcDy3b um+jtlxmWiD26cSpuESSz7E= =WBf9 -----END PGP SIGNATURE----- --GlnCQLZWzqLRJED8--