Re: optimizer ignoring primary key and doing sequence scan

From: Ragnar <gnari(at)hive(dot)is>
To: Edoardo Panfili <edoardo(at)aspix(dot)it>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: optimizer ignoring primary key and doing sequence scan
Date: 2008-07-15 09:28:50
Message-ID: 1216114130.15516.21.camel@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On þri, 2008-07-15 at 08:19 +0200, Edoardo Panfili wrote:
> Scott Marlowe ha scritto:
> > On Mon, Jul 14, 2008 at 1:54 PM, Chris Hoy <chris(dot)hoy(at)hoyc(dot)fsnet(dot)co(dot)uk> wrote:
> >>
> >> select * from industries where industryid = 1;
> >> "Seq Scan on industries (cost=0.00..1.02 rows=1 width=116) (actual
> >> time=0.011..0.013 rows=1 loops=1)"
> >
> > According to this there's only one row in the table. why WOULD
> > postgresql use an index when it can just scan the one row table in a
> > split second.
> >
> I agree with you that it can depend on the size of the table but where
> you can read that the table contains only one row?

it does not really say 1 row, but you can infer from the estimated cost,
that the table is only 1 block (cost=0.00..1.02). that is the smallest
read unit.
using an index would cost 2 random reads.

> I try with my table (39910 rows, no index on column note)
> explain analyze select * from table where note='single example';
>
> Seq Scan on table (cost=0.00..2458.88 rows=13 width=327) (actual
> time=10.901..481.896 rows=1 loops=1)

surely this is not the same table

gnari

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Teodor Sigaev 2008-07-15 09:29:54 Re: [GENERAL] Fragments in tsearch2 headline
Previous Message valgog 2008-07-15 09:00:57 Re: Multithreaded queue in PgSQL