[rt-devel] Postgres performance.

Jesse Vincent jesse at bestpractical.com
Wed Apr 9 22:05:57 EDT 2003


What aidan is working on is recasting all the joins as explicit joins. 
Because of the toolkit we use to do the dynamic generation, it's a
single code path to change.



On Wed, Apr 09, 2003 at 10:02:57PM -0400, Greg Stark wrote:
> David Wheeler <david at kineticode.com> writes:
> 
> > On Wednesday, April 9, 2003, at 05:08  AM, Aidan Mountford wrote:
> > 
> > > Unless anyone can see a reason why I should stop this, I will carry on
> > > down this path..
> > 
> > I, for one, would welcome the increased performance. It's pretty bad right
> > now.
> 
> Aren't these queries dynamically generated? How can you rewrite them like this
> in a general way?
> 
> There is one disadvantage of explicit joins like you're using: They restrict
> postgres's degrees of freedom which in theory reduces postgres's ability to
> optimize.
> 
> That may sound silly given the speed difference you're seeing, but numbers can
> be deceiving. Most of that difference is coming directly from a single tricky
> join clause. If you can really play with the query you could try simply moving
> the groups_2.id = whatever.id clause outside the OR.
> 
> Also, you may want to try the queries with the CVS version of postgres. It
> will treat the explicit paths very differently from the way 7.3 does and might
> not do exactly what you expect.
> 
> That said, I usually prefer explicit joins myself because I find them
> infinitely more readable than old style queries. But I would suggest ordering
> the tables the way you want them so you don't need the 10 nested
> parentheses...
> 
> I'm still curious why postgres is having trouble with that OR clause. I can't
> seem to come up with any simple example queries that trigger that behaviour.
> By all means consider sending it on to postgres-general, sending there
> generally elicits helpful contributions. I would mention the groups table and
> point out the relevant clause of the query specifically.
> 
> --
> greg
> 
> _______________________________________________
> rt-devel mailing list
> rt-devel at lists.fsck.com
> http://lists.fsck.com/mailman/listinfo/rt-devel

-- 
http://www.bestpractical.com/rt  -- Trouble Ticketing. Free.



More information about the Rt-devel mailing list