Re: Re: PG regression with row comparison when btree_gist is enabled (BUG) - Mailing list pgsql-bugs

From Tom Lane
Subject Re: Re: PG regression with row comparison when btree_gist is enabled (BUG)
Date
Msg-id 21086.1309646333@sss.pgh.pa.us
Whole thread Raw
In response to Re: PG regression with row comparison when btree_gist is enabled (BUG)  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: Re: PG regression with row comparison when btree_gist is enabled (BUG)  (Jeff Davis <pgsql@j-davis.com>)
Re: Re: PG regression with row comparison when btree_gist is enabled (BUG)  (Jeff Davis <pgsql@j-davis.com>)
List pgsql-bugs
Jeff Davis <pgsql@j-davis.com> writes:
> On Sat, 2011-06-18 at 13:20 -0700, Jeff Davis wrote:
>> Interesting problem... the bug is in get_op_btree_interpretation() which
>> has code like this:
>> ...
>> However, that's a bogus test, because btree_gist puts <> into an
>> opfamily. Thus, catlist->n_members == 1 even though we really do need to
>> look for the negator. Really, we need to unconditionally search for the
>> operator as well as unconditionally searching for the negator.

> Patch attached.

I looked at this a bit.  The proposed patch is inadequate, aside from
any excess lookups it introduces, because there is similar logic in
predtest.c.  To make the world safe for btree_gist to do this, we'd have
to add extra lookup activity there as well.

Quite honestly, I think that the bug is that btree_gist took it upon
itself to invent <> as an indexable operator.  The odds that that will
ever be of practical use seem negligible, and not at all adequate to
warrant adding extra cycles into mainstream code paths.  It's not too
late to rip that out of 9.1, and that's what I think we should do.

            regards, tom lane

pgsql-bugs by date:

Previous
From: Maxim Boguk
Date:
Subject: Re: BUG #6088: copy to stdout cannot be stopped with kill(pid) or pg_terminate_backend
Next
From: Jeff Davis
Date:
Subject: Re: Re: PG regression with row comparison when btree_gist is enabled (BUG)