On 12/17/2015 02:17 PM, David Rowley wrote:
On 17 December 2015 at 19:11, Simon Riggs <si...@2ndquadrant.com
On 17 December 2015 at 00:17, Tomas Vondra
I'd go with match_first_tuple_only.
unique_inner is a state that has been detected,
match_first_tuple_only is the action we take as a result.
Ok great. I've made it so in the attached. This means the comment in the
join code where we perform the skip can be a bit less verbose and all
the details can go in where we're actually setting the
match_first_tuple_only to true.
OK. I've looked at the patch again today, and it seems broken bv
45be99f8 as the partial paths were not passing the unique_inner to the
create_*_path() functions. The attached patch should fix that.
Otherwise I think the patch is ready for committer - I think this is a
valuable optimization and I see nothing wrong with the code.
Any objections to marking it accordingly?
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
diff --git a/src/backend/optimizer/path/joinpath.c b/src/backend/optimizer/path/joinpath.c
index be410d2..1ec2ddc 100644
@@ -411,7 +411,7 @@ try_partial_nestloop_path(PlannerInfo *root,
* Before creating a path, get a quick lower bound on what it is likely
* to cost. Bail out right away if it looks terrible.
- initial_cost_nestloop(root, &workspace, jointype,
+ initial_cost_nestloop(root, &workspace, jointype, extra->unique_inner,
if (!add_partial_path_precheck(joinrel, workspace.total_cost, pathkeys))
@@ -422,6 +422,7 @@ try_partial_nestloop_path(PlannerInfo *root,
@@ -622,6 +623,7 @@ try_partial_hashjoin_path(PlannerInfo *root,
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: