Re: Let an ordering index scan hand its ORDER BY value to the target list

Hello,

v9 attached, rebased on master (6b9f40d49ae). It fixes a bug I found
in 0001.

The bug: box_ops shouldn't have qualified for amcanreturnorderby. Its
GiST and SP-GiST leaf distances are exact arithmetic on the box, but
<->(box, point) goes through dist_bp(), which treats a point within
EPSILON of an edge's line as on it. So the index can hand back a
value that differs from the operator's in the last digits:

-- box ((0,0),(1,1)), point (0.9999996, 2)
operator 1.00000000000008
GiST/SP-GiST scan 1

Only the point opclasses qualify now (GiST point_ops, SP-GiST
quad_point_ops and kd_point_ops), whose leaf distance calls
point_distance() itself. That also withdraws the box <-> point result
in my numbers mail (-27.1%). The other numbers posted on this thread
don't involve box_ops.

The other changes:

* amcanreturnorderby takes (opfamily, opcintype, orderbyop) instead of
(Relation, attno), like amtranslatecmptype. Whether the values are
exact depends on the ordering operator, and one opfamily can hold
several. The planner keeps the callback in IndexOptInfo like
amcostestimate, so plancat.c no longer fills a per-column array.
(0001, 0002)

* An ordering IndexScan's ORDER BY value now has to pass the same
10 * cpu_operator_cost test as an index-only scan's before it is
carried up through a join. A plain point distance used to turn off
add_path_precheck() for every join above the scan, only for the
join to drop the value. (0006)

* use_physical_tlist() lets an index-only scan return its indextlist
when every extra value is already an index column, which fixes the
8% overhead the HammerDB run found (index-only scan node 11.5-12.2 ms
-> 9.6-10.2 ms in an A/B on that query). (0006)

* apply_scanjoin_target_to_paths() re-sorts a path list whenever it
replaced any path with a projection. It used to re-sort only when
the targets' exprs differed, but a path that emits extra values gets
a projection even when they're the same, and its cost can move.
(0005)

* At an outer join, setrefs.c's search_indexed_tlist_for_nulled_expr()
now requires the upper copy's nullingrels to be a superset of the
input's, as the comment always claimed and as it does for Vars. It
also strips each input tlist once rather than once per candidate,
and the cost side checks strictness only on a match. (0007)

* The ordered Append and MergeAppend collect their children the way
generate_orderedappend_paths() does, so child_append_relid_sets
means what it should. (0007)

* expr_contains() and strip_nullingrels() moved to clauses.c, and
credit_free_context is in typedefs.list from 0006. A few smaller
cleanups too, and some stale comments fixed.

New tests:
- SP-GiST point value equality, plus the box case above;
- the reorder queue with one exact and one lossy key;
- a LATERAL rescan;
- FULL JOIN, Gather Merge and Parallel Append;
- an isolation spec, eval-plan-qual-knn, showing that EvalPlanQual
hands back the updated row's distance.

best.

-greg