Re: Performance improvement for joins where outer side is unique

From: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
To: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Performance improvement for joins where outer side is unique
Date: 2016-01-22 16:36:02
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers


On 12/17/2015 02:17 PM, David Rowley wrote:
> On 17 December 2015 at 19:11, Simon Riggs <simon(at)2ndquadrant(dot)com
> <mailto:simon(at)2ndquadrant(dot)com>> wrote:
> On 17 December 2015 at 00:17, Tomas Vondra
> <tomas(dot)vondra(at)2ndquadrant(dot)com <mailto:tomas(dot)vondra(at)2ndquadrant(dot)com>>
> wrote:
> I'd go with match_first_tuple_only.
> +1
> 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
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Attachment Content-Type Size
unijoin-partial.patch application/x-patch 1.2 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2016-01-22 16:40:24 Re: WIP: Failover Slots
Previous Message Robert Haas 2016-01-22 16:34:27 Re: Releasing in September