| 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: | Whole Thread | Raw Message | 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
| 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 |