Re: index / sequential scan problem - Mailing list pgsql-performance

From Tom Lane
Subject Re: index / sequential scan problem
Date
Msg-id 5494.1058464980@sss.pgh.pa.us
Whole thread Raw
In response to Re: index / sequential scan problem  (Paul Thomas <paul@tmsl.demon.co.uk>)
List pgsql-performance
Paul Thomas <paul@tmsl.demon.co.uk> writes:
> 2) enable_seqscan = false
>> Seq Scan on notiz_objekt a  (cost=100000000.00..100111719.36 rows=15561
>> width=12) (actual time=0.25..535.75 rows=31122 loops=1)

> I've just noticed this. Something is not right here. Look at the crazy
> cost estimation for the second query.

No, that's exactly what it's supposed to do.  enable_seqscan cannot
simply suppress generation of a seqscan plan (because that might be
the only way to do the query, if there's no applicable index).  So it
generates the plan, but sticks a large penalty into the cost estimate
to keep the planner from choosing that alternative if there is any
other.  The "100000000.00" is that artificial penalty.

We could probably hide this implementation detail from you if we tried
hard enough, but it hasn't bothered anyone enough to try.

            regards, tom lane

pgsql-performance by date:

Previous
From: Jord Tanner
Date:
Subject: Re: Hardware performance
Next
From: Tom Lane
Date:
Subject: Re: index / sequential scan problem