ajkon [игнорируется] 

Обычно подобное решается через заведение отдельного поля LAST_UPDATED где дата последнего обновления или возрастающий счетчик.
Соответственно, при чтениях просто указывается LAST_UPDATED > последней_даты_чтения для кэша. Если есть какие-то нюансы с тем, что читать не все config_id необходимо и производительность не удовлетворительная, то можно и config_id добавить в условие и создать подходящий индекс: config_id, last_updated.

Индексы на не равно: обычно это решается через переписывания не равно в больше/меньше, например:
prod_version_id != 5006 - prod_version_id < 5006 or prod_version_id > 5006.
Индекс будет на config_id, prod_version_id. Но нужно смотреть план выполнения, т.к. в PostgreSQL не должно быть concatenation/or-expansion трансформаций, что есть в Oracle. Т.е. возможно переписать в UNION ALL, в зависимости от плана.

Далее, почему prod_version_id != 5006? Возможно ли использовать prod_version_id > 5006, или по каким-то причинам поле не возрастает?
Тогда опять будет индекс на config_id, prod_version_id и смотреть план.

Если всё-таки нужно не равно и переписывать ничего нельзя, то просто создать индекс на config_id, prod_version_id.
По плану в PostgreSQL будет использоваться доступ по config_id (оно уникально из-за primary key) + фильтр по prod_version_id, т.е. это проверяется на основании индекса и уже затем по отфильтрованным данным будет доступ в таблицу для получения blablabla.