Re: Make the planner smarter about idiosyncratic (or broken) ORM behaviour

From: Richard Huxton <dev(at)archonet(dot)com>
To: Frank Jördens <frank(at)woome(dot)com>
Cc: pgsql-sql(at)postgresql(dot)org, Nic Ferrier <nferrier(at)woome(dot)com>, Edward George <ed(at)woome(dot)com>, Seb Potter <seb(at)woome(dot)com>, Hannu Krosing <hannu(at)2ndquadrant(dot)com>
Subject: Re: Make the planner smarter about idiosyncratic (or broken) ORM behaviour
Date: 2009-05-22 09:56:49
Message-ID: 4A1676E1.6010102@archonet.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

Frank Jördens 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
going to be an uphill struggle to get patches accepted unless there is a
simple, quick can-merge-two-joins test someone can come up with. Time
spent planning to deal with badly written queries costs every
well-written query too of course.

Even with a patch and acceptance from core, 8.4 is in beta at the moment
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
days and have him/her hack the ORM to make it less, um, "simplistic"?
There must be an "assemble references into JOINs" point in the code you
could rationalise this at.

--
Richard Huxton
Archonet Ltd

In response to

Responses

Browse pgsql-sql by date

  From Date Subject
Next Message Richard Huxton 2009-05-22 10:33:35 Re: Make the planner smarter about idiosyncratic (or broken) ORM behaviour
Previous Message Frank Jördens 2009-05-22 09:33:43 Make the planner smarter about idiosyncratic (or broken) ORM behaviour