Re: [PgFoundry] Unsigned Data Types [1 of 2]

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

In response to

Responses

Browse pgsql-patches by date

  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