Re: Incorrect index used in few cases..
От | Tom Lane |
---|---|
Тема | Re: Incorrect index used in few cases.. |
Дата | |
Msg-id | 25880.1560896580@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Incorrect index used in few cases.. (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Incorrect index used in few cases..
|
Список | pgsql-performance |
Andres Freund <andres@anarazel.de> 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
В списке pgsql-performance по дате отправления: