<literal><></literal></member>
<member><function>scalarltsel</function> for <literal><</literal></member>
<member><function>scalarlesel</function> for <literal><=</literal></member>
<member><function>scalargtsel</function> for <literal>></literal></member>
<member><function>scalargesel</function> for <literal>>=</literal></member>
</simplelist>
</para>
<para>
You can frequently get away with using either <function>eqsel</function> or <function>neqsel</function> for
operators that have very high or very low selectivity, even if they
aren't really equality or inequality. For example, the
approximate-equality geometric operators use <function>eqsel</function> on the assumption that
they'll usually only match a small fraction of the entries in a table.
</para>
<para>
You can use <function>scalarltsel</function>, <function>scalarlesel</function>,
<function>scalargtsel</function> and <function>scalargesel</function> for comparisons on
data types that have some sensible means of being converted into numeric
scalars for range comparisons. If possible, add the data type to those
understood by the function <function>convert_to_scalar()</function> in
<filename>src/backend/utils/adt/selfuncs.c</filename>.
(Eventually, this function should be replaced by per-data-type functions
identified through a column of the <classname>pg_type</classname> system catalog; but that hasn't happened
yet.) If you do not do this, things will still work, but the optimizer's
estimates won't be as good as they could be.
</para>
<para>
Another useful built-in selectivity estimation function
is <function>matchingsel</function>, which will work for almost any
binary operator, if standard MCV and/or histogram statistics are
collected for the input data type(s). Its default estimate is set to
twice the default estimate used in <function>eqsel</function>, making
it most suitable for comparison operators that are somewhat less
strict than equality. (Or you could call the
underlying <function>generic_restriction_selectivity</function>
function, providing a different default estimate.)
</para>
<para>
There are additional selectivity estimation functions designed for geometric
operators in <filename>src/backend/utils/adt/geo_selfuncs.c</filename>: <function>areasel</function>, <function>positionsel</function>,
and <function>contsel</function>. At this writing these are just stubs, but you might want
to use them (or even better, improve them) anyway.
</para>
</sect2>
<sect2 id="xoper-join">
<title><literal>JOIN</literal></title>
<para>
The <literal>JOIN</literal> clause, if provided, names a join selectivity
estimation function for the operator. (Note that this is a function
name, not an operator name.) <literal>JOIN</literal> clauses only make sense for
binary operators that return <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>