Just a few suggestions
(1) Make sure you have run the VACUUM ANALYZE command on the table
(i.e. VACUUM ANALYZE tipo_categoria)
(2) Try running the following 3 commands, and comparing the total costs to
see which is cheaper (an index scan is *not* always best). If the
sequential scan is cheaper,
arias
DÃgitro Tecnologia - Brasil
- Original Message -
From: Tom Lane <[EMAIL PROTECTED]>
To: Vilson farias <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; SIMONE Carla MOSENA
<[EMAIL PROTECTED]>
Sent: Sexta-feira, 10 de Novembro de 2000 13:11
Subject: Re
"Vilson farias" <[EMAIL PROTECTED]> writes:
> sitest=# CREATE TABLE tipo_categoria (
> sitest(#cod_categoriasmallint NOT NULL,
> sitest(#descricaovarchar(40),
> sitest(#CONSTRAINT XPKtipo_categoria PRIMARY KEY (cod_categoria)
> sitest(#
> sitest(# );
>
On Fri, Nov 10, 2000 at 10:16:47AM -0200, Vilson farias wrote:
> result of execution is a sequencial scan, but this is a PRIMARY KEY, it does
> has an index. How can it be explained?
If you wish use index, then you need include ORDER BY clause. AFAIK
two SELECTs on same data without ORDER BY _CAN
Subject: [GENERAL] Sequencial scan over primary keys
:
: Hello,
:
: I need help in case below. My table tipo_categoria has a primary key,
: called cod_categoria When I use this key as parameter for my sql script,
the
: result of execution is a sequencial scan, but this is a PRIMARY KEY, it
does
:
Hello,
I need help in case below. My table tipo_categoria has a primary key,
called cod_categoria When I use this key as parameter for my sql script, the
result of execution is a sequencial scan, but this is a PRIMARY KEY, it does
has an index. How can it be explained?
sitest=# CREATE TAB
