From: | Jeff Frost <jeff(at)pgexperts(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #6092: specific casting required for gist indexing of bigint |
Date: | 2011-07-06 17:14:41 |
Message-ID: | 4E149801.40507@pgexperts.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-07-06 17:25:53 | Re: Re: PG regression with row comparison when btree_gist is enabled (BUG) |
Previous Message | Jeff Davis | 2011-07-06 17:00:11 | Re: Re: PG regression with row comparison when btree_gist is enabled (BUG) |