Re: Duplicate WHERE condition changes performance and plan

> If you're using SSD storage, or if the DB is small compared with shared_buffers or RAM, then random_page_cost should be closer to seq_page_cost.

I don't *think* we are using SSDs  but I'll need to confirm that though.

> How large are the indexes? problem_id_idx1 ?

Using the query from here:
https://wiki.postgresql.org/wiki/Index_Maintenance#Index_size.2Fusage_statistics
Output here: https://gist.github.com/indy-singh/e33eabe5cc937043c93b42a8783b3bfb

I've setup a repo here where it is possible to reproduce the weird
behaviour I'm getting:-

https://github.com/indy-singh/postgres-duplicate-where-conditon

That contains the data (amended to remove any private information) as
well as the statements need to recreate tables, indices, and
constraints,

I think after some trial and error this is something to do with the
size of the table and statistics. I've been trying to put together a
Short, Self Contained, Correct example (http://sscce.org/) and the
problem only appears when fill problem_instance.message with junk, but
I have to do it in two steps as outlined in the README in repo.

Indy