From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Svenne Krap <usenet(at)krap(dot)dk> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: explain, planner and more.. |
Date: | 2001-08-15 04:23:24 |
Message-ID: | 24654.997849404@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Svenne Krap <usenet(at)krap(dot)dk> writes:
> Why does the planner choose not to use numberdomain_pkey as index on
> numberdomain ?
> -> Seq Scan on numberdomain nd (cost=0.00..1.85
> rows=1 width=31)
Evidently because it thinks numberdomain only has one disk block,
and hence there's no possible savings from reading an index in addition
to that one disk block. (If it were estimating more than one block
read then the cost estimate would be 2 or more. 1.85 implies one block
read = 1.0 cost unit, plus some per-tuple CPU effort.)
If numberdomain is indeed big enough to warrant an index search,
then you need to VACUUM it to update the planner's statistics.
The plan you are getting is based on statistics that say numberdomain
is tiny.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Stephan Szabo | 2001-08-15 04:38:05 | Re: Null Conversion |
Previous Message | Mike Withers | 2001-08-15 03:56:27 | Re: Null Conversion |