From: Tom Lane <tgl@sss.pgh.pa.us>
To: Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
cc: sk@zsrv.org, michael.paquier@gmail.com, x4mmm@yandex-team.ru,
        david@nlpgo.com, pgsql-hackers@postgresql.org
Subject: Re: Index-only scan returns incorrect results when using a composite
 GIST index with a gist_trgm_ops column.
In-reply-to: <20180307.092638.115232766.horiguchi.kyotaro@lab.ntt.co.jp>
References: <348951516742031@web54j.yandex.ru>
 <20180124.161153.214591193.horiguchi.kyotaro@lab.ntt.co.jp>
 <22609.1519936758@sss.pgh.pa.us>
 <20180307.092638.115232766.horiguchi.kyotaro@lab.ntt.co.jp>
Comments: In-reply-to Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
	message dated "Wed, 07 Mar 2018 09:26:38 +0900"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <14642.1539629304.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Mon, 15 Oct 2018 14:48:24 -0400
Message-ID: <14643.1539629304@sss.pgh.pa.us>
Precedence: bulk

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 i=
n <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=3Djaguarundi&dt=3D=
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