RE: primary key scans in sequence - Mailing list pgsql-sql

From Stephan Szabo
Subject RE: primary key scans in sequence
Date
Msg-id Pine.BSF.4.21.0105301044300.6432-100000@megazone23.bigpanda.com
Whole thread Raw
In response to RE: primary key scans in sequence  ("Koen Antonissen" <Koen@Cee-Kay.net>)
List pgsql-sql
On Wed, 30 May 2001, Koen Antonissen wrote:

> Now this one doesn't:
>                              Table "teams"
>  Attribute |  Type   |                     Modifier                     
> -----------+---------+--------------------------------------------------
>  id        | integer | not null default nextval('teams_id_seq'::text)
>  name      | text    | not null
>  mgr_name  | text    | 
>  address   | text    | 
>  zipcode   | text    | 
>  city      | text    | 
>  country   | text    | 
>  email     | text    | 
>  telnr     | text    | 
>  mobnr     | text    | 
>  faxnr     | text    | 
>  logo      | text    | not null default 'images/teams/logo_default.gif'
>  movie     | text    | 
>  url       | text    | 
>  qoute     | text    | 
>  active    | boolean | default 't'::bool
> Indices: index_teams_id, <=!!! 'my own' index
>          index_teams_name,
>          teams_pkey,    <=normal pkey index
>          unq_teams_name
> 
> NOTICE:  QUERY PLAN:
> 
> Seq Scan on teams  (cost=0.00..1.09 rows=1 width=173)

Looking at that cost, I have to wonder, how many rows are in the table
and has vacuum analyze been run on it?  If the number of rows in the
table is small, the seq scan is definately better than having to read
from both the index and heap.



pgsql-sql by date:

Previous
From: Tom Lane
Date:
Subject: Re: Case Insensitive Queries
Next
From: "Richard Huxton"
Date:
Subject: Re: bpchar compares (was Re: Case Insensitive Queries)