Re: why sequential scan is used on indexed column ??? - Mailing list pgsql-general

From Tom Lane
Subject Re: why sequential scan is used on indexed column ???
Date
Msg-id 17123.1213468538@sss.pgh.pa.us
Whole thread Raw
In response to Re: why sequential scan is used on indexed column ???  (Michael Fuhr <mike@fuhr.org>)
Responses Re: why sequential scan is used on indexed column ???  (Julius Tuskenis <julius.tuskenis@gmail.com>)
Re: why sequential scan is used on indexed column ???  (Michael Fuhr <mike@fuhr.org>)
List pgsql-general
Michael Fuhr <mike@fuhr.org> writes:
> I created a test case that has close to the same estimated and
> actual row counts and has the same plan if I disable enable_nestloop:

There's something weird about this --- why does the second plan seqscan
b_saskaita, instead of using the bitmap scan that it had previously
estimated to be cheaper?  What PG version are you testing, and can you
provide the full test case?

(As for the original question, the hash plan seems to me to be perfectly
reasonable for the estimated row counts --- fetching one row out of
fifty using an indexscan is going to be expensive.  So I think the OP's
problem is purely a statistical one, or maybe he's in a situation where
he should reduce random_page_cost.)

            regards, tom lane

pgsql-general by date:

Previous
From: Michael Fuhr
Date:
Subject: Re: why sequential scan is used on indexed column ???
Next
From: Alvaro Herrera
Date:
Subject: Re: dblink() cursor error/issue (TopMemoryContext)