Could you please take a look at this one once again?
On Fri, Dec 18, 2015 at 10:23 AM, Grzegorz Garlewicz <grzegorz@thulium.pl>
wrote:
> 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@sss.pgh.pa.us> wrote:
>
>> grzegorz@thulium.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
>>
>
>
