Обсуждение: comparing index columns

<br clear="all" />Hi,<br /><br />As per HOT design, a necessary condition to do HOT updates is<br />that an index
columnmust not be updated. I am invoking the type<br />specific equality operator to compare two index columns,
something<br />like this (which I think I had copied from ri_KeysEqual(), but that too have<br />changed now):<br /><br
/>           typeid = SPI_gettypeid(relation->rd_att, attrnum);<br />            typentry =
lookup_type_cache(typeid,TYPECACHE_EQ_OPR_FINFO); <br /><br />            if
(!OidIsValid(typentry->eq_opr_finfo.fn_oid))<br/>                ereport(ERROR,<br />                       
(errcode(ERRCODE_UNDEFINED_FUNCTION),<br/>                                errmsg("could not identify an equality
operator" <br />                                "for type %s", format_type_be(typeid))));<br /><br />            /*<br
/>            * Call the type specific '=' function<br />             */<br />            if
(!DatumGetBool(FunctionCall2(&(typentry->eq_opr_finfo),<br />                                             
oldvalue,newvalue)))<br />                return true;<br />        <br />Heikki pointed out that this may not work
correctlywith operator classes<br />where we should actually be using the operator from the given operator class <br
/>insteadof the default operator of the type.<br /><br />I don't have much insight into the operator classes and
operatorfamilies<br />and how they work. Where should I look for the related code ? Is there<br />anything else we
shouldbe worried about as well ? <br /><br />Any help is appreciated.<br /><br /><br />Thanks,<br />Pavan<br /><br />--
<br/>Pavan Deolasee<br />EnterpriseDB     <a href="http://www.enterprisedb.com">http://www.enterprisedb.com</a> 

"Pavan Deolasee" <pavan.deolasee@gmail.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.deolasee@gmail.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@enterprisedb.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