Re: GiST Comparing IndexTuples/Datums - Mailing list pgsql-hackers

From Tom Lane
Subject Re: GiST Comparing IndexTuples/Datums
Date
Msg-id 23920.1171743888@sss.pgh.pa.us
Whole thread Raw
In response to Re: GiST Comparing IndexTuples/Datums  ("Matthew Campbell" <mtthw.cmpbll@gmail.com>)
List pgsql-hackers
"Matthew Campbell" <mtthw.cmpbll@gmail.com> writes:
> revisit hash to see if we can figure it out now that we understand a little
> bit about GiST, but we can't find an equivelent function in hash for the
> KeyIsEQ().
>     So two questions really.  The first is if such a function exists for
> hash.

hash indexes don't have any need to compare two entries so you're
unlikely to find a bit of code that does exactly that, but the
HTEqualStrategyNumber member of the index's operator class is the
relevant equality operator, so it's surely possible to invoke it.
You could just do that directly instead of bothering with scankeys.
The only reason _bt_check_unique uses a scankey is that that's the
information it's already got, because btree generates a scankey for use
in searching the index for the correct insertion position.  There's
no comparable need in hash and hence no infrastructure for it.

It'd go something like
Oid    cmp_op = indexrel->rd_operator[HTEqualStrategyNumber-1];
RegProcedure cmp_proc = get_opcode(cmp_op);
if (!RegProcedureIsValid(cmp_proc))    elog...
result = DatumGetBool(OidFunctionCall2(cmp_proc, datum1, datum2));

although you'd probably want to avoid looking up the function again
for each index entry, so plan on an fmgr_info call in there.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Martijn van Oosterhout
Date:
Subject: Re: RFC: Temporal Extensions for PostgreSQL
Next
From: elein
Date:
Subject: Re: New feature request: FlashBack Query