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

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

postgres$# $$ language sql strict;@H_404_1@

CREATE FUNCTION@H_404_1@

postgres=# select f_avg(1,null);@H_404_1@

f_avg@H_404_1@

-------@H_404_1@

@H_404_1@

(1 row)@H_404_1@

postgres=# select f_avg(1,2);@H_404_1@

f_avg @H_404_1@

--------------------@H_404_1@

1.5000000000000000@H_404_1@

(1 row)@H_404_1@

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

UPDATE 1@H_404_1@

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

UPDATE 1@H_404_1@

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

QUERY PLAN @H_404_1@

---------------------------------------------------------------------------@H_404_1@

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

Index Cond: (id < 10)@H_404_1@

(2 rows)@H_404_1@

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

QUERY PLAN @H_404_1@

----------------------------------------------------------@H_404_1@

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

Filter: (10 > id)@H_404_1@

(2 rows)@H_404_1@

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

UPDATE 1@H_404_1@

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

UPDATE 1@H_404_1@

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

QUERY PLAN @H_404_1@

---------------------------------------------------------------------------@H_404_1@

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

Index Cond: (id < 10)@H_404_1@

(2 rows)@H_404_1@

/*----------@H_404_1@

* Operator selectivity estimation functions are called to estimate the@H_404_1@

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

* We divide the problem into two cases:@H_404_1@

* Restriction clause estimation: the clause involves vars of just@H_404_1@

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

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

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

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

*@H_404_1@

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

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

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

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

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

*@H_404_1@

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

*@H_404_1@

* Selectivity oprrest (PlannerInfo *root,@H_404_1@

* Oid operator,@H_404_1@

* List *args,@H_404_1@

* int varRelid);@H_404_1@

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

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

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

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

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

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

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

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

*@H_404_1@

* This is represented at the sql level (in pg_proc) as@H_404_1@

*@H_404_1@

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

*@H_404_1@

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

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

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

*@H_404_1@

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

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

* supplied:@H_404_1@

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

* Selectivity oprjoin (PlannerInfo *root,@H_404_1@

* JoinType jointype,@H_404_1@

* SpecialJoinInfo *sjinfo);@H_404_1@

*@H_404_1@

* float8 oprjoin (internal,int2,internal);@H_404_1@

*@H_404_1@

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

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

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

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

* best ignored in favor of examining sjinfo.@H_404_1@

*@H_404_1@

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

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

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

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

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

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

*@H_404_1@

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

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

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

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

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

* should ignore the actual operator collation and use DEFAULT_COLLATION_OID.@H_404_1@

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

* to justify complicating matters.@H_404_1@

*----------@H_404_1@