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,

* JoinType jointype,

* SpecialJoinInfo *sjinfo);

*

* float8 oprjoin (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,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.

*----------