Re: BUG #6092: specific casting required for gist indexing of bigint

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jeff Frost <jeff(at)pgexperts(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #6092: specific casting required for gist indexing of bigint
Date: 2011-07-06 19:16:45
Message-ID: 25123.1309979805@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Jeff Frost <jeff(at)pgexperts(dot)com> writes:
> On 07/05/11 17:06, Tom Lane wrote:
>> "Jeff Frost" <jeff(at)pgexperts(dot)com> writes:
>>> Ran into a situation with a customer who is using the btree_gist contrib
>>> module to allow combined index of some tsearch data and two other columns.
>>> One of these other columns is a bigint field. I noticed that the combined
>>> index won't be used by the planner unless you specifically cast the bare
>>> number to a bigint.

>> If memory serves, the btree_gist opclasses don't include any cross-type
>> operators, so "int8 = int4" doesn't work here.

> Ah! And if you look at the contrib/btree_gist/sql/int8.sql test file, you'll
> see this:
> SELECT count(*) FROM int8tmp WHERE a < 464571291354841::int8;
> So, I'd say it's expected behavior even though it's slightly counter intuitive
> if you're used to the auto typing behavior.

Well, it might be nice to fix it sometime, but I'd characterize it as an
unimplemented feature in btree_gist, not a bug.

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message wbc 2011-07-07 02:36:28 BUG #6093: timeout
Previous Message Tom Lane 2011-07-06 18:59:47 Re: Re: PG regression with row comparison when btree_gist is enabled (BUG)