Received: from localhost (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with ESMTP id 37203476520; Wed, 9 Oct 2002 13:31:13 -0400 (EDT) Received: from megazone.bigpanda.com (megazone.bigpanda.com [63.150.15.178]) by postgresql.org (Postfix) with ESMTP id 8259C476527; Wed, 9 Oct 2002 13:31:12 -0400 (EDT) Received: by megazone.bigpanda.com (Postfix, from userid 1001) id 68A09D60C; Wed, 9 Oct 2002 10:31:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by megazone.bigpanda.com (Postfix) with ESMTP id 5C3FB5C03; Wed, 9 Oct 2002 10:31:12 -0700 (PDT) Date: Wed, 9 Oct 2002 10:31:12 -0700 (PDT) From: Stephan Szabo To: Jose Antonio Leo Cc: , Subject: Re: [SQL] problem with the Index In-Reply-To: Message-ID: <20021009102800.U4728-100000@megazone23.bigpanda.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS new-20020517 X-Archive-Number: 200210/515 X-Sequence-Number: 31513 On Wed, 9 Oct 2002, Jose Antonio Leo wrote: > I have a problem with the index of 1 table. > > I hava a table created : > CREATE TABLE "acucliart" ( > "cod_pto" numeric(8,0) NOT NULL, > "cod_cli" varchar(9) NOT NULL, > "mes" numeric(2,0) NOT NULL, > "ano" numeric(4,0) NOT NULL, > "int_art" numeric(5,0) NOT NULL, > "cantidad" numeric(12,2), > "ven_siv_to" numeric(14,2), > "ven_civ_to" numeric(14,2), > "tic_siv_to" numeric(14,2), > "tic_civ_to" numeric(14,2), > "visitas" numeric(2,0), > "ult_vis" date, > "ven_cos" numeric(12,2), > "ven_ofe" numeric(12,2), > "cos_ofe" numeric(12,2), > CONSTRAINT "acucliart_pkey" > PRIMARY KEY ("cod_cli") > ); > > if i do this select: > explain select * from acucliart where cod_cli=10000; > postgres use the index > NOTICE: QUERY PLAN: > Index Scan using cod_cli_ukey on acucliart (cost=0.00..4.82 rows=1 > width=478) > > and this select > explain select * from acucliart where cod_cli>10000; > Postgres don't use the index: > NOTICE: QUERY PLAN: > Seq Scan on acucliart (cost=0.00..22.50 rows=333 width=478) > > why? Well, how many rows are in the table? In the first case it estimates 1 row will be returned, in the second 333. Index scans are not always faster than sequential scans as the percentage of the table to scan becomes larger. If you haven't analyzed recently, you probably should do so and if you want to compare, set enable_seqscan=off and try an explain there and see what it gives you. Also, why are you comparing a varchar(9) column with an integer?