From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | AminPG Jaffer <aminjaffer(dot)pg(at)gmail(dot)com>, pgsql-performance(at)lists(dot)postgresql(dot)org |
Subject: | Re: Incorrect index used in few cases.. |
Date: | 2019-06-18 22:23:00 |
Message-ID: | 25880.1560896580@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Andres Freund <andres(at)anarazel(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Chris Wilson | 2019-06-20 15:12:18 | EXPLAIN ANALYZE of BRIN bitmap index scan with disjunction |
Previous Message | Andres Freund | 2019-06-18 22:13:46 | Re: Incorrect index used in few cases.. |