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 54EF4B80.7020902@2ndquadrant.com
Whole thread Raw
In response to Re: Performance improvement for joins where outer side is unique  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Responses Re: Performance improvement for joins where outer side is unique  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 26.2.2015 01:15, Tomas Vondra wrote:
>
> I'm not quite sure why, but eclassjoin_is_unique_join() never actually
> jumps into this part (line ~400):
> 
>     if (relvar != NULL && candidaterelvar != NULL)
>     {
>         ...
>         index_vars = lappend(index_vars, candidaterelvar);
>         ...
>     }
> 
> so the index_vars is NIL. Not sure why, but I'm sure you'll spot the
> issue right away.

FWIW this apparently happens because the code only expect that
EquivalenceMembers only contain Var, but in this particular case that's
not the case - it contains RelabelType (because oprcode is regproc, and
needs to be relabeled to oid).

Adding this before the IsA(var, Var) check fixes the issue

   if (IsA(var, RelabelType))       var = (Var*) ((RelabelType *) var)->arg;

but this makes the code even more confusing, because 'var' suggests it's
a Var node, but it's RelabelType node.

Also, specialjoin_is_unique_join() may have the same problem, but I've
been unable to come up with an example.


regards

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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Precedence of standard comparison operators
Next
From: Andrew Dunstan
Date:
Subject: Re: Precedence of standard comparison operators