Re: Performance improvement for joins where outer side is unique
От | Tomas Vondra |
---|---|
Тема | Re: Performance improvement for joins where outer side is unique |
Дата | |
Msg-id | 56A25A72.2090505@2ndquadrant.com обсуждение исходный текст |
Ответ на | 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
Re: Performance improvement for joins where outer side is unique |
Список | 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
Вложения
В списке pgsql-hackers по дате отправления: