Re: Weird indices

Tom Lane wrote:
>
> Joseph Shraibman <jks@selectacast.net> writes:
> > Stephan Szabo wrote:
> >> Do you have a value that is not null that is very common?
> >> It's estimating that there will be 10113 rows that match
> >> nomsession='xxx' which makes a seq scan a much less bad plan.
> >>
> > Err, why?  There is an index, isn't there?  Shouldn't the index allow
> > postgres to quickly find the %2 of rows that would match?
>
> Define "quickly".
>
> > sitefr=# explain select nomsession from session where nomsession='xxx';
> > NOTICE:  QUERY PLAN:
> >
> > Seq Scan on session  (cost=0.00..16275.95 rows=10113 width=12)
>
> We have here an estimate that 10113 rows will be matched (out of the
> 510069 in the table).  The table contains something on the order of
> 16000 pages (guesstimate from the seqscan cost estimate).  The planner
> is assuming that the 10113 rows are randomly scattered in the table,
> and therefore that the executor will have to fetch the majority of the
> pages in the table.  Under these circumstances a seqscan is cheaper
> than an indexscan, because it works with the Unix kernel's preference
> for sequential reads (to say nothing of the disk drive's ;-)), instead
> of fighting that optimization.  Random fetches are more than twice as
> expensive as sequential fetches.
>
> Of course, if the 10113-match estimate is wildly off (as it was in this
> case), then the wrong plan may be chosen.  But it IS NOT CORRECT to
> suppose that indexscans always beat seqscans.  The planner's job would
> be a lot easier if that were true.
>
>                         regards, tom lane

Can't postgres do the index lookup first and find out there are only a
few tuples that might match?

--
Joseph Shraibman
jks@selectacast.net
Increase signal to noise ratio.  http://www.targabot.com