Propagate LIMIT bound through the outer side of left join

Hi,

This thread continues part [1] on Top-N sort propagation. It's a separate
feature with its own positive effect.

The attached patch enables executor-stage propagation of a limit bound down to
the outer side of a LEFT or FULL join node in the ExecSetTupleBound(). It works
when there's no filtering clause in the upper part of the query tree.

The feature delivers a clear benefit that can be demonstrated with the following
example.

CREATE TEMP TABLE a AS
SELECT (random() * 1E6)::int AS x FROM generate_series(1, 1E6);
CREATE TEMP TABLE b AS
SELECT g::int AS y from generate_series(1, 1E6) g;
CREATE INDEX ON b(y);
VACUUM ANALYZE a, b;

\timing on

SELECT * FROM (SELECT * FROM a ORDER BY x) s LEFT JOIN b ON s.x = b.y LIMIT 10;

And after warming up executions you can see something like the following:
Time: 63.771 ms — master
Time: 32.578 ms — patched

This feature works the same way for each join type. But the most probable
potential beneficiary now is the merge join node. So most of the added
regression tests force a merge join.

As usual, it is not a clean win. In cases where the user wants a dominant share
of the input tuples, quicksort is more effective than bounded sort. I treat this
as a normal case because it isn't new, and the planner's cost model bases its
decision on quite relaxed empirical ‘tuples > 2 × limit’ rule, preferring
bounded sort in many cases.

[1] Try a presorted outer path when referenced by an ORDER BY prefix
https://www.postgresql.org/message-id/f0dc7fcb-4034-4b5c-bfe6-1e7b8817cd36%40gmail.com

--
regards, Andrei Lepikhov,
pgEdge