Re: Index-only scan returns incorrect results when using a composite GIST index with a gist_trgm_ops column.

Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> writes:
> At Thu, 01 Mar 2018 15:39:18 -0500, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote in <22609(dot)1519936758(at)sss(dot)pgh(dot)pa(dot)us>
>> ... After some poking
>> around I found that the bug could be exhibited using just btree_gist's
>> gist_inet_ops, since the core inet_ops class indexes the same datatype and
>> it does have a fetch function. So I added a test case in btree_gist.

> Ah, It wasn't in my sight to test core in contrib. Thanks for
> improving it.

I've just noticed that this new test case is sometimes failing on
CLOBBER_CACHE_ALWAYS buildfarm animals, eg here:

https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jaguarundi&dt=2018-10-14%2022%3A11%3A00

(I've seen some similar failures before but hadn't looked into the
reason for them.)

I can duplicate the plan choice shown here if I stick in "ANALYZE
inettmp", so presumably what is happening is that sometimes a
background auto-analyze is managing to run and change the rowcount
estimate.

We don't really care about bitmap indexscan vs regular here, rather
about index-only vs regular, so there's not anything much wrong with
using the post-ANALYZE behavior. So I think what we should do to
make this test case more stable is to change the VACUUM to VACUUM
ANALYZE and accept the ensuing change in expected plan.

I doubt this test failure would ever occur in normal builds, so I'm
not going to risk touching it immediately before a release wrap.
But I'll make the change tomorrow or so.

regards, tom lane