From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
cc: AminPG Jaffer <aminjaffer.pg@gmail.com>,
        pgsql-performance@lists.postgresql.org
Subject: Re: Incorrect index used in few cases..
In-reply-to: <20190618221346.a5ql6n5s2zaheufb@alap3.anarazel.de>
References: 
 <CAJ9dAqn5UzOQ4wVoCxXPGEu3+WJeZ35xY0bijA4XEpizU8SS5g@mail.gmail.com>
 <802.1560864908@sss.pgh.pa.us>
 <CAJ9dAq=mvWapLyo7y-ERc4WD=7cFM3nP9Zx_F6-zAdSnezX_=g@mail.gmail.com>
 <23028.1560892075@sss.pgh.pa.us>
 <20190618221346.a5ql6n5s2zaheufb@alap3.anarazel.de>
Comments: In-reply-to Andres Freund <andres@anarazel.de>
	message dated "Tue, 18 Jun 2019 15:13:46 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <25879.1560896580.1@sss.pgh.pa.us>
Date: Tue, 18 Jun 2019 18:23:00 -0400
Message-ID: <25880.1560896580@sss.pgh.pa.us>
Precedence: bulk

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