"Ross J. Reedstrom" <reedstrm@rice.edu> writes:
> Matt -
> We've been running into exactly the same problems you, for exactly the
> same reason: we have a highly 'normalized' database design, in order to
> easily populate drop-downs and picklists (get the users to enter the
> right data by only giving them the right data!) You don't mention what
> version of PostgreSQL you're using, but I bet it's 6.4.2. The
> development team found some nasty problems in the query optimzer that
> caused exactly these symptoms, and there are fixes in v6.5beta.
I think Ross has the right idea --- the 6.4.x optimizer has serious
problems for queries that require joining more than about ten tables
(since the number of possible ways to do the joins grows exponentially).
GEQO is better but can still take an unreasonably long time. Although
6.5 is considerably quicker than 6.x, I still suspect that planning a
20-way join will take way longer than you'd like it to.
If you have some kind of application in front of your database, you
can avoid the need for the join planning by just retrieving the raw
data and doing the substitutions at the application end, using local
copies of the data from the auxiliary tables. I do this extensively
in my own company's apps and it works just fine. (You pretty much
need a local copy of each table anyway if you're going to present
choices in popup menus...)
regards, tom lane
