Ronuk Raval <ronuk.raval@xxxxxxxxx> writes: > We've been working around the problem by rewriting queries to use UNION instead. Yeah, that. The real issue here is that the seqscan and indexscan plans both suck, because they will both run that sub-select for every row in the table. The index-only plan might fetch fewer blocks along the way, because it only has to read the index not the table proper ... but that's only true if the table's pages are mostly marked all-visible. (My bet about the plan instability is that the planner might choose differently depending on how much of the table it believes is all-visible.) That only helps a bit, though. What you really want to have happen, assuming there are not too many interesting orderid values, is to do a point indexscan for each one of them. Currently the planner won't think of that by itself when faced with OR'd conditions in WHERE. You have to help it along with UNION or some similar locution. regards, tom lane
