Re: BUG #13824: EXISTS sometimes uses seq scan instead of index

I did just what you said - reduced random_page cost from 4 to 2 then 1 and
then 0.5. Neither did change anything (in fact I did not believe it would
change anything but did the test anyway).
If I'm not mistaken, the issue seems to originate from the planner's
thinking it needs to look up all the rows for EXISTS clause, not just a
single one, so it thinks the cost would be much bigger.
regards,
grzegorz

On Fri, Dec 18, 2015 at 2:17 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> grzegorz(at)thulium(dot)pl writes:
> > Whenever I perform select like below, planner thinks it's going to look
> up
> > many rows and falls back to seq scan. If I disable seq scan, it correctly
> > uses the index.
>
> You might need to reduce random_page_cost to reflect your environment
> better ... especially if you're most concerned about performance with
> all data already cached in memory, which is what these examples are
> probably showing.
>
> regards, tom lane
>