Jan Walter <john@commontongue.com> writes:
> I would like to know, how does the size of the IN list affect query planner.
AFAICT, the reason the second plan is slow is the large number of checks
of the IN list. The planner does account for the cost of that, but it's
drastically underestimating that cost relative to the cost of I/O for the
heap and index accesses. I suppose that your test case is fully cached in
memory, which helps make the CPU costs more important than I/O costs.
If you think this is representative of your real workload, then you
need to decrease random_page_cost (and maybe seq_page_cost too) to make
the cost estimates correspond better to that reality.
regards, tom lane
