Message-ID: <4A1676E1.6010102@archonet.com>
Date: Fri, 22 May 2009 10:56:49 +0100
From: Richard Huxton <dev@archonet.com>
User-Agent: Thunderbird 2.0.0.21 (X11/20090320)
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Frank_J=F6rdens?= <frank@woome.com>
CC: pgsql-sql@postgresql.org, Nic Ferrier <nferrier@woome.com>,
	Edward George <ed@woome.com>,
	Seb Potter <seb@woome.com>, Hannu Krosing <hannu@2ndquadrant.com>
Subject: Re: Make the planner smarter about idiosyncratic (or broken)
	ORM 	behaviour
References: <7d10d2df0905220233v3e54ab34lb9c3530fe3543a5c@mail.gmail.com>
In-Reply-To: <7d10d2df0905220233v3e54ab34lb9c3530fe3543a5c@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Frank J=F6rdens wrote:
> Our Django experts are telling me that it is probably not practical to
> fix in the ORM, as it seems to be structural (anyway not fixable for
> us in the near term). Hence I am wondering if anyone has an idea as to
> how to make the planner smarter about such weirdness (or brokenness);
> you might argue that the 2nd join there is merely syntactic bloat
> which the planner might just recognize as such?

Even if you have funding to hire a developer to adapt PG's planner, it's=20
going to be an uphill struggle to get patches accepted unless there is a=20
simple, quick can-merge-two-joins test someone can come up with. Time=20
spent planning to deal with badly written queries costs every=20
well-written query too of course.

Even with a patch and acceptance from core, 8.4 is in beta at the moment=20
so you'll have a long wait before 8.5 comes out with your patch.

Are you sure it wouldn't be easier to hire a Python guru for a couple of=20
days and have him/her hack the ORM to make it less, um, "simplistic"?=20
There must be an "assemble references into JOINs" point in the code you=20
could rationalise this at.

--=20
   Richard Huxton
   Archonet Ltd