<type>boolean</type>. The idea behind a join
selectivity estimator is to guess what fraction of the rows in a
pair of tables will satisfy a <literal>WHERE</literal>-clause condition of the form:
<programlisting>
table1.column1 OP table2.column2
</programlisting>
for the current operator. As with the <literal>RESTRICT</literal> clause, this helps
the optimizer very substantially by letting it figure out which
of several possible join sequences is likely to take the least work.
</para>
<para>
As before, this chapter will make no attempt to explain how to write
a join selectivity estimator function, but will just suggest that
you use one of the standard estimators if one is applicable:
<simplelist>
<member><function>eqjoinsel</function> for <literal>=</literal></member>
<member><function>neqjoinsel</function> for <literal><></literal></member>
<member><function>scalarltjoinsel</function> for <literal><</literal></member>
<member><function>scalarlejoinsel</function> for <literal><=</literal></member>
<member><function>scalargtjoinsel</function> for <literal>></literal></member>
<member><function>scalargejoinsel</function> for <literal>>=</literal></member>
<member><function>matchingjoinsel</function> for generic matching operators</member>
<member><function>areajoinsel</function> for 2D area-based comparisons</member>
<member><function>positionjoinsel</function> for 2D position-based comparisons</member>
<member><function>contjoinsel</function> for 2D containment-based comparisons</member>
</simplelist>
</para>
</sect2>
<sect2 id="xoper-hashes">
<title><literal>HASHES</literal></title>
<para>
The <literal>HASHES</literal> clause, if present, tells the system that
it is permissible to use the hash join method for a join based on this
operator. <literal>HASHES</literal> only makes sense for a binary operator that
returns <literal>boolean</literal>, and in practice the operator must represent
equality for some data type or pair of data types.
</para>
<para>
The assumption underlying hash join is that the join operator can
only return true for pairs of left and right values that hash to the
same hash code. If two values get put in different hash buckets, the
join will never compare them at all, implicitly assuming that the
result of the join operator must be false. So it never makes sense
to specify <literal>HASHES</literal> for operators that do not represent
some form of equality. In most cases it is only practical to support
hashing for operators that take the same data type on both sides.
However, sometimes it is possible to design compatible hash functions
for two or more data types; that is, functions that will generate the
same hash codes for <quote>equal</quote> values, even though the values
have different representations. For example, it's fairly simple
to arrange this property when hashing integers of different widths.
</para>
<para>
To be marked <literal>HASHES</literal>, the join operator must appear
in a hash index operator family. This is not enforced when you create
the operator, since of course the referencing operator family couldn't
exist yet. But attempts to use the operator in hash joins will fail
at run time if no such operator family exists. The system needs the
operator family to find the data-type-specific hash function(s) for the
operator's input data type(s). Of course, you must also create suitable
hash functions before you can create the operator family.
</para>
<para>
Care should be exercised when preparing a hash function, because there
are machine-dependent ways in which it might fail to do the right thing.
For example, if your data type is a structure in which there might