postgres = # create function f_avg(numeric,numeric) returns numeric as $$

postgres$#   select ($1+$2)/2;

postgres$# $$ language sql strict;

CREATE FUNCTION

postgres = # select f_avg(1,null);

 f_avg 

-------

(1 row)

postgres=# select f_avg(1,2);

       f_avg        

--------------------

 1.5000000000000000

(1 row)

postgres = # update pg_operator set oprcom=0 where oprname='>' and oprcode='int4gt'::regproc;

UPDATE 1

postgres=# update pg_operator set oprcom=0 where oprname='<' and oprcode='int4lt'::regproc;

UPDATE 1

postgres = # explain select * from tbl where id<10;

                                QUERY PLAN                                 

---------------------------------------------------------------------------

 Index Only Scan using idx_tbl_id on tbl  (cost=0.29..8.45 rows=9 width=4)

   Index Cond: (id < 10)

(2 rows)

postgres=# explain select * from tbl where 10>id;

                        QUERY PLAN                        

----------------------------------------------------------

 Seq Scan on tbl  (cost=0.00..1361.00 rows=33333 width=4)

   Filter: (10 > id)

(2 rows)

postgres = # update pg_operator set oprcom=521 where oprname='<' and oprcode='int4lt'::regproc;

UPDATE 1

postgres=# update pg_operator set oprcom=97 where oprname='>' and oprcode='int4gt'::regproc;

UPDATE 1

postgres=# explain select * from tbl where 10>id;

                                QUERY PLAN                                 

---------------------------------------------------------------------------

 Index Only Scan using idx_tbl_id on tbl  (cost=0.29..8.45 rows=9 width=4)

   Index Cond: (id < 10)

(2 rows)

/*----------

 * Operator selectivity estimation functions are called to estimate the

 * selectivity of WHERE clauses whose top-level operator is their operator.

 * We divide the problem into two cases:

 *              Restriction clause estimation: the clause involves vars of just

 *                      one relation.  一种是符合WHERE条件的选择性（百分比）。

 *              Join clause estimation: the clause involves vars of multiple rels.

 * Join selectivity estimation is far more difficult and usually less accurate

 * than restriction estimation.  -- JOIN的选择性评估通常没有WHERE条件的选择性准确。

 *

 * When dealing with the inner scan of a nestloop join, we consider the

 * join's joinclauses as restriction clauses for the inner relation, and

 * treat vars of the outer relation as parameters (a/k/a constants of unknown

 * values).  So, restriction estimators need to be able to accept an argument

 * telling which relation is to be treated as the variable.

 *

 * The call convention for a restriction estimator (oprrest function) is

 *

 *              Selectivity oprrest (PlannerInfo *root,

 *                                                       Oid operator,

 *                                                       List *args,

 *                                                       int varRelid);

 * 评估选择性需要4个参数:

 * root: general information about the query (rtable and RelOptInfo lists

 * are particularly important for the estimator).   plannerinfo信息。

 * operator: OID of the specific operator in question. 操作符的OID

 * args: argument list from the operator clause.  操作符子句中的参数列表

 * varRelid: if not zero, the relid (rtable index) of the relation to

 * be treated as the variable relation.  May be zero if the args list

 * is known to contain vars of only one relation.   表示where条件所包含的参数来自哪些relation。

 *

 * This is represented at the SQL level (in pg_proc) as

 *

 *              float8 oprrest (internal, oid, internal, int4);   在pg_proc数据字典中表示为oprrest指定的函数。

 *

 * The result is a selectivity, that is, a fraction (0 to 1) of the rows

 * of the relation that are expected to produce a TRUE result for the

 * given operator.  选择性函数的评估结果就是一个百分比。乘以pg_class.reltuples就可以得到记录数。

 *

 * The call convention for a join estimator (oprjoin function) is similar

 * except that varRelid is not needed, and instead join information is

 * supplied:

 * JOIN选择性的计算函数与WHERE选择性的计算函数参数有轻微差别，么有varRelid, 增加了join信息的参数。

 *              Selectivity oprjoin (PlannerInfo *root,

 *                                                       Oid operator,

 *                                                       List *args,

 *                                                       JoinType jointype,

 *                                                       SpecialJoinInfo *sjinfo);

 *

 *              float8 oprjoin (internal, oid, internal, int2, internal);

 *

 * (Before Postgres 8.4, join estimators had only the first four of these

 * parameters.  That signature is still allowed, but deprecated.)  The

 * relationship between jointype and sjinfo is explained in the comments for

 * clause_selectivity() --- the short version is that jointype is usually

 * best ignored in favor of examining sjinfo.

 *

 * Join selectivity for regular inner and outer joins is defined as the

 * fraction (0 to 1) of the cross product of the relations that is expected

 * to produce a TRUE result for the given operator.  For both semi and anti  (半连接与预连接)

 * joins, however, the selectivity is defined as the fraction of the left-hand

 * side relation's rows that are expected to have a match (ie, at least one

 * row with a TRUE result) in the right-hand side.

 *

 * For both oprrest and oprjoin functions, the operator's input collation OID

 * (if any) is passed using the standard fmgr mechanism, so that the estimator

 * function can fetch it with PG_GET_COLLATION().  Note, however, that all

 * statistics in pg_statistic are currently built using the database's default

 * collation.  Thus, in most cases where we are looking at statistics, we

 * should ignore the actual operator collation and use DEFAULT_COLLATION_OID.

 * We expect that the error induced by doing this is usually not large enough

 * to justify complicating matters.

 *----------