Received: from localhost (maia-1.hub.org [200.46.204.191]) by postgresql.org (Postfix) with ESMTP id 6C1F79FB5F5 for ; Tue, 12 Jun 2007 10:47:21 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.191]) (amavisd-maia, port 10024) with ESMTP id 33043-01-2 for ; Tue, 12 Jun 2007 10:47:15 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from mtai03.charter.net (mtai03.charter.net [209.225.8.183]) by postgresql.org (Postfix) with ESMTP id 87BD19FB5FD for ; Tue, 12 Jun 2007 10:47:12 -0300 (ADT) Received: from aa07.charter.net ([10.20.200.159]) by mtai03.charter.net (InterMail vM.7.08.02.00 201-2186-121-20061213) with ESMTP id <20070612134711.BYTY1549.mtai03.charter.net@aa07.charter.net>; Tue, 12 Jun 2007 09:47:11 -0400 Received: from [10.0.1.2] (really [66.188.164.45]) by aa07.charter.net with ESMTP id <20070612134711.XPAL8059.aa07.charter.net@[10.0.1.2]>; Tue, 12 Jun 2007 09:47:11 -0400 In-Reply-To: <466EA078.20601@mecola.com> References: <466EA078.20601@mecola.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6336D034-24D7-47B3-8690-9E7561E5432C@seespotcode.net> Cc: pgsql-performance@postgresql.org Content-Transfer-Encoding: 7bit From: Michael Glaesemann Subject: Re: test / live environment, major performance difference Date: Tue, 12 Jun 2007 08:47:05 -0500 To: Christo Du Preez X-Mailer: Apple Mail (2.752.2) X-Chzlrs: 0 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200706/203 X-Sequence-Number: 25236 On Jun 12, 2007, at 8:32 , Christo Du Preez wrote: > I have noticed that my server never uses indexing. No matter what I > do. > > As an example I took a table with about 650 rows, having a parentid > field with an index on parentid. > > EXPLAIN ANALYZE > SELECT * > FROM layertype > where parentid = 300; The planner weighs the cost of the different access methods and choses the one that it believes is lowest in cost. An index scan is not always faster than a sequential scan. With so few rows, it's probably faster for the server to read the whole table rather than reading the index and looking up the corresponding row. If you want to test this, you can set enable_seqscan to false and try running your query again. http://www.postgresql.org/docs/8.2/interactive/runtime-config- query.html#RUNTIME-CONFIG-QUERY-ENABLE Michael Glaesemann grzm seespotcode net