From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | Lorraine(dot)Dewey(at)companiongroup(dot)com (Lorraine Dewey), pgsql-sql(at)postgresql(dot)org |
Subject: | Re: Optomizing left outer joins |
Date: | 2003-04-23 18:49:32 |
Message-ID: | 200304231149.32514.josh@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
Lorraine,
> Since some of the data fields are optional and I won't be able to
> match across tables, I need to use left outer joins to make sure I
> don't drop rows. Unfortunately, execution time is somewhere around a
> minute (there's other stuff going on, but the majority of the time is
> in the execution). Way too long. For comparison, my queries run in
> about 2 seconds when I don't have to do outer joins.
FWIW, outer joins are slower than regular joins on all RDBMSs I've tested --
often up to 5 times slower. I'm not sure whether this is just the planner
restricitons inherent in an outer join, or whether this is something about
the required join algorithm itself.
The general solution is not to allow nulls in join columns. For example, I
recently had to force one of my clients to add 0: Not Selected to all of
their reference lists to make those columns NOT NULL. Their reports run 80%
faster now.
> I never know which columns the users will pick so I can't really
> hardcode the queries. Everything is generated on the fly. I've been
> asked not to index any columns. Any ideas about how I can make this
> thing run faster so I can drop the workaround, or any alternative
> ideas? I think we're using version 7.3.2.
If the client is tying your hands, you'll have to use a workaround. Make sure
you tell them so ;->
--
-Josh Berkus
Aglio Database Solutions
San Francisco
From | Date | Subject | |
---|---|---|---|
Next Message | mallah | 2003-04-23 18:51:45 | Re: Why is seq search preferred here by planner? |
Previous Message | Richard Huxton | 2003-04-23 18:30:32 | Re: Invoice Numbers |