Thread: Re: Index-only scan returns incorrect results when using a composite GIST index with a gist_trgm_ops column.
Re: Index-only scan returns incorrect results when using a composite GIST index with a gist_trgm_ops column.
From
Tom Lane
Date:
Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> writes: > At Thu, 01 Mar 2018 15:39:18 -0500, Tom Lane <tgl@sss.pgh.pa.us> wrote in <22609.1519936758@sss.pgh.pa.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