Rod Taylor <[EMAIL PROTECTED]> writes:
> It's the = operator that Slony adds for xxid comparisons. I didn't even
> think of changes Slony would have made.
> ssdb=# select * from pg_operator where oid = 716373;
> oprname | oprnamespace | oprowner | oprkind | oprcanhash | oprleft |
> oprright | oprresult | oprcom | oprnegate | oprlsortop | oprrsortop |
> oprltcmpop | oprgtcmpop | oprcode | oprrest | oprjoin
> ---------+--------------+----------+---------+------------+---------+----------+-----------+--------+-----------+------------+------------+------------+------------+---------------+---------+-----------
> = | 2200 | 588 | b | t | 716353 |
> 716353 | 16 | 716373 | 716372 | 716371 | 716371 |
> 716371 | 716369 | _ssrep.xxideq | eqsel | eqjoinsel
> (1 row)
I think you need to have a word with the Slony boys. They shouldn't be
marking the operator oprcanhash if they aren't providing a valid hash
opclass for the datatype. Per the manual:
: To be marked HASHES, the join operator must appear in a hash index
: operator class. This is not enforced when you create the operator, since
: of course the referencing operator class couldn't exist yet. But
: attempts to use the operator in hash joins will fail at runtime if no
: such operator class exists. The system needs the operator class to find
: the data-type-specific hash function for the operator's input data
: type. Of course, you must also supply a suitable hash function before
: you can create the operator class.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
