Andres Freund <andres@xxxxxxxxxxx> writes: > Are those indexes used for other queries? Any chance they've been > recently created? > SELECT indexrelid::regclass, xmin, indcheckxmin, indisvalid, indisready, > indislive, txid_current(), txid_current_snapshot() > FROM pg_index WHERE indrelid = 'tc'::regclass; > might tell us. Oh, that's a good idea. > Amin, might be worth to see what the query plan is if you disable that > index. I assume it's too big to quickly drop (based on the ? Considering that the "right" query plan would have a cost estimate in the single digits or close to it, I have to suppose that the planner is rejecting that index as unusable, not making a cost-based decision not to use it. (Well, maybe if it's bloated by three orders of magnitude compared to the other indexes, it'd lose on cost. Doesn't seem likely though.) So I think we're looking for a hard "can't use the index" reason, and now we've eliminated datatype mismatch which'd be the most obvious such reason. But index-isnt-valid or index-isnt-ready might do the trick. regards, tom lane
