From: | "Ryan Bradetich" <rbradetich(at)gmail(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Jaime Casanova" <jcasanov(at)systemguards(dot)com(dot)ec>, pgsql-patches <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: [PgFoundry] Unsigned Data Types [1 of 2] |
Date: | 2008-09-09 15:14:59 |
Message-ID: | e739902b0809090814j55a75d6dm213432b87f4b0c5f@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Hello Tom,
On Tue, Sep 9, 2008 at 5:11 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Ryan Bradetich" <rbradetich(at)gmail(dot)com> writes:
>> I am assuming you are seeing this error in the uint_test1.sql:
>> ERROR: could not find hash function for hash operator 16524
>> I can bypass the error in uint_test1.sql by disabling the hash joins.
>> I am going to dig in and figure out why the hashjoin operation is broken.
>
> Well, the cause of that one would've been marking an operator as HASHES
> without providing a hash opclass to back it up.
Actually I did provide a hash operator class in the patch:
CREATE OPERATOR CLASS uint4_ops
DEFAULT FOR TYPE uint4 USING HASH AS
OPERATOR 1 =,
FUNCTION 1 hashuint4(uint4);
This only provides the operator class for uint4 eq uint4. Jaime's test case
was uint4 eq int4 which I did not have an operator class for. I was able to fix
this test case by adding the int4 eq uint4 operator like this:
CREATE OPERATOR CLASS uint4_ops
DEFAULT FOR TYPE uint4 USING HASH FAMILY unsigned_integer_ops AS
OPERATOR 1 =,
FUNCTION 1 hashuint4(uint4);
ALTER OPERATOR FAMILY unsigned_integer_ops USING HASH ADD
OPERATOR 1 = (int4, uint4),
FUNCTION 1 hashuint4_from_int4(int4);
I tested uint4 eq int4 and int4 eq uint4 and this one additional hash operator
handles them both.
[NOTE: The other solution was to cast foo to the uint4 data type.]
I am working on adding support for the int4 eq uint2 and int4 eq uint1 cases
as well. I am running into an error when I add support for these hash operator
classes that I am not quite ready to post about yet (I want to look a
bit more first).
> IIRC the test case involved ">"? That shouldn't even be marked HASHES
> anyway ...
That error was in the uint_test2 test case Jaime provided.
This test case looks like:
drop table if exists t1_uint4;
create table t1_uint4 (f1 uint4 primary key);
insert into t1_uint4 select generate_series(1, 255);
analyze t1_uint4;
select * from t1_uint4, generate_series(1, 10) as foo where t1_uint4.f1 = foo;
Thanks,
- Ryan
From | Date | Subject | |
---|---|---|---|
Next Message | Alex Hunsaker | 2008-09-10 01:23:03 | Re: hash index improving v3 |
Previous Message | Kenneth Marshall | 2008-09-09 13:48:39 | Re: hash index improving v3 |