Quite so! Therefore,
gds2=# explain analyze select boundary from lg where section=14;
NOTICE: QUERY PLAN:
Index Scan using lgsec on lg (cost=0.00..12167.45 rows=3836 width=32)
(actual time=44.98..18325.87 rows=3759 loops=1)
Total runtime: 18344.06 msec
EXPLAIN
gds2=# set enable_seqscan=on;
SET VARIABLE
gds2=# explain analyze select boundary from lg where section=14;
NOTICE: QUERY PLAN:
Seq Scan on lg (cost=0.00..5885.77 rows=3836 width=32) (actual
time=0.24..2974.65 rows=3759 loops=1)
Total runtime: 2987.61 msec
EXPLAIN
Smart planner...curiosity: what is that first number following cost= and
actual time=?
Thank you again.
Don
Tom Lane wrote:
>Don Isgitt <djisgitt@soundenergy.com> writes:
>
>>gds2=# explain select * from lg where section=14;
>>NOTICE: QUERY PLAN:
>>
>
>>Seq Scan on lg (cost=0.00..5885.77 rows=3836 width=73)
>>
>
>>EXPLAIN
>>gds2=# set enable_seqscan=off;
>>SET VARIABLE
>>gds2=# explain select * from lg where section=14;
>>NOTICE: QUERY PLAN:
>>
>
>>Index Scan using lgsec on lg (cost=0.00..12167.45 rows=3836 width=73)
>>
>
>>EXPLAIN
>>
>
>Of course, the above only proves that the planner thinks the indexscan
>will be slower ;-). You should try EXPLAIN ANALYZE to see how well the
>planner estimates square up with reality ...
>
> regards, tom lane
>
>