comparing index columns

Hi,

As per HOT design, a necessary condition to do HOT updates is
that an index column must not be updated. I am invoking the type
specific equality operator to compare two index columns, something
like this (which I think I had copied from ri_KeysEqual(), but that too have
changed now):

typeid = SPI_gettypeid(relation->rd_att, attrnum);
typentry = lookup_type_cache(typeid, TYPECACHE_EQ_OPR_FINFO);

if (!OidIsValid(typentry->eq_opr_finfo.fn_oid))
ereport(ERROR,
(errcode(ERRCODE_UNDEFINED_FUNCTION),
errmsg("could not identify an equality
operator "
"for type %s", format_type_be(typeid))));

/*
* Call the type specific '=' function
*/
if (!DatumGetBool(FunctionCall2(&(typentry->eq_opr_finfo),
oldvalue, newvalue)))
return true;

Heikki pointed out that this may not work correctly with operator classes
where we should actually be using the operator from the given operator class
instead of the default operator of the type.

I don't have much insight into the operator classes and operator families
and how they work. Where should I look for the related code ? Is there
anything else we should be worried about as well ?

Any help is appreciated.

Thanks,
Pavan

--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com

"Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com> writes:
> I don't have much insight into the operator classes and operator families
> and how they work. Where should I look for the related code ?

Primary opclass members are stored right in the Relation data struct for
you. Since (I trust) you're only supporting this for btree, you could
just use rd_supportinfo[0] which will not even cost an fmgr lookup.
See index_getprocinfo() and callers.

regards, tom lane

Tom Lane wrote:
> "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com> writes:
>> I don't have much insight into the operator classes and operator families
>> and how they work. Where should I look for the related code ?
>
> Primary opclass members are stored right in the Relation data struct for
> you. Since (I trust) you're only supporting this for btree, you could
> just use rd_supportinfo[0] which will not even cost an fmgr lookup.
> See index_getprocinfo() and callers.

There's currently no reason to limit HOT to b-trees.

How about just doing a memcmp? That would be safe, simple and fast and
covers all interesting use cases.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

Heikki Linnakangas <heikki(at)enterprisedb(dot)com> writes:
> How about just doing a memcmp? That would be safe, simple and fast and
> covers all interesting use cases.

You'd have to use datumIsEqual() or equivalent, and figure out what to
do about nulls. I think it'd work though, at least for the purposes
that HOT needs. There are failure cases; for example a previously
not-toasted index key column could get toasted due to expansion of an
unrelated data column. But +1 for speed over accuracy here, as long as
it can never make a false equality report.

regards, tom lane