Here is a rebased version of the patch set.
Since the last version, production use has exposed that the 'optimistic'
strategy doesn't work safely: we can't suppose during planning that the outer of
the LEFT JOIN returns no more than 'limit_tuples' rows. Some pushed-down clause
that lands as a join filter in the LEFT JOIN chain might cause the scan node to
return (and sort) far more tuples than planned.
This patch set employs an opportunistic approach: the plan estimation part
assumes full sort of the rows returned by the Scan, and the executor's
ExecSetTupleBound applies boundaries on the Sort node if no one LEFT JOIN node
in the chain contains filters.
The most beneficial strategy should employ something like a Top-Down 'smoothing'
pass after the planning stage, as mentioned [1] in earlier threads. An
alternative approach is a kind of subtree replanning, as the commit [2] has
demonstrated recently.
[1]
https://www.postgresql.org/message-id/494586a2-fd9b-44ad-9bb5-4b6cc18bdf53%40gmail.com
[2]
https://www.postgresql.org/message-id/E1x020n-00000002XCr-0lpe@gemulon.postgresql.org
--
regards, Andrei Lepikhov,
pgEdge
