Re: Performance improvement for joins where outer side is unique - Mailing list pgsql-hackers

From Tomas Vondra
Subject Re: Performance improvement for joins where outer side is unique
Date
Msg-id 56A25A72.2090505@2ndquadrant.com
Whole thread Raw
In response to Re: Performance improvement for joins where outer side is unique  (David Rowley <david.rowley@2ndquadrant.com>)
Responses Re: Performance improvement for joins where outer side is unique  (David Rowley <david.rowley@2ndquadrant.com>)
Re: Performance improvement for joins where outer side is unique  (David Rowley <david.rowley@2ndquadrant.com>)
List pgsql-hackers
Hi,

On 12/17/2015 02:17 PM, David Rowley wrote:
> On 17 December 2015 at 19:11, Simon Riggs <simon@2ndquadrant.com
> <mailto:simon@2ndquadrant.com>> wrote:
>
>     On 17 December 2015 at 00:17, Tomas Vondra
>     <tomas.vondra@2ndquadrant.com <mailto:tomas.vondra@2ndquadrant.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?

regards

--
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Attachment

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Releasing in September
Next
From: Robert Haas
Date:
Subject: Re: WIP: Failover Slots