Predicate migration on complex self joins

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Predicate migration on complex self joins
Date: 2009-07-13 16:16:59
Message-ID: 1247501819.11347.1112.camel@ebony.2ndQuadrant
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


In some cases, we have SQL being submitted that has superfluous
self-joins. An example would be

select count(*)
from foo1 a, foo1 b
where a.c1 = b.c1 /* PK join */
and a.c2 = 5
and b.c2 = 10;

We can recognise that <a> and <b> are the same table because they are
joined on the PK. PK is never NULL, so a join b == a in set terms. We
can use this to re-write the query as if all predicates on either of the
two aliases were on the LHS only. e.g. rewrite query like this:

select count(*)
from foo1 a, foo1 b
where a.c1 = b.c1
and a.c2 = 5
and a.c2 = 10; /* predicate migration */

Predicate migration is important because it either allows us to detect
impossible logic, as above, or to use multi-column index access/ bitmap
scans, or to allow join removal of the RHS as a superfluous join. (I
believe that self-joins were not originally part of the analysis of
potentially removable joins).

You may well ask who would be stupid enough to write SQL like that. The
answer is of course that it is automatically generated by an ORM.

Implementing something along these lines is secondary to join removal,
but it seems worth noting as non-high priority item for the TODO.

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2009-07-13 17:16:49 Re: Upgrading our minimum required flex version for 8.5
Previous Message Alvaro Herrera 2009-07-13 15:54:28 Re: (No) Autocast in 8.4 with operators "=" and "LIKE"