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 -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql
