As for the index on the status, it's because we have a job that runs every night that deals with conversations in specific statuses. Having a low cardinality index that changes frequently seems prone to mis-use by the system. -> What would be an alternative ?
One option would be a partial index on another field used in that query where status in ( list_of_uncommon_statuses_queried_nightly )
Sequential scan may be perfectly fine for a nightly script though.
Чтобы сделать работу с сайтом удобнее, мы используем cookie и аналитический сервис «Яндекс.Метрика». Продолжая пользоваться сайтом, вы соглашаетесь с их использованием.