Re: [HACKERS] Slow - grindingly slow - query - Mailing list pgsql-hackers

From Brian Hirt
Subject Re: [HACKERS] Slow - grindingly slow - query
Date
Msg-id 19991112120207.A27778@loopy.berkhirt.com
Whole thread Raw
In response to Re: [HACKERS] Slow - grindingly slow - query  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] Slow - grindingly slow - query
List pgsql-hackers
On Fri, Nov 12, 1999 at 09:58:14AM -0500, Tom Lane wrote:
> Brian Hirt <bhirt@mobygames.com> writes:
> > Can't the rewrite engine recognize a simple case like the 
> > one above and rewrite it to use exists and not exists with the proper 
> > joins?  Or possibly the optimizer can generate a better plan?
> 
> This is on the TODO list, and will get done someday.  IMHO it's not as
> urgent as a lot of the planner/optimizer's other shortcomings, because
> it can usually be worked around by revising the query.
> 
> If it's bugging you enough to go fix it now, contributions are always
> welcome ;-)
> 

Okay, what would be the correct approach to solving the problem, 
and where would be a good place to start?  I'v only been on this list
for a few weeks, so I'm missed discussion on the approach to solving 
this problem.  Should this change be localized to just the planner? 
Should the rewrite system be creating a different query tree?  Will both 
need to be changed?  If a lot of work is being done to this part of 
the system, is now a bad time to try this work?

I'm willing to jump in to this, but I may take a while to figure it out 
and ask a lot of questions that are obvious to the hardened postgres 
programmer.  I'm not famaliar with the postgres code, yet. 


-brian

-- 
The world's most ambitious and comprehensive PC game database project.
                     http://www.mobygames.com


pgsql-hackers by date:

Previous
From: "gov-boi"
Date:
Subject: www.hack.co.za - exploit archives updates - 0day
Next
From: Don Baccus
Date:
Subject: Re: [HACKERS] compression in LO and other fields