Re: Performance woes - Mailing list pgsql-general

From Tom Lane
Subject Re: Performance woes
Date
Msg-id 3060.1134432704@sss.pgh.pa.us
Whole thread Raw
In response to Re: Performance woes  (Benjamin Smith <lists@benjamindsmith.com>)
Responses Re: Performance woes
List pgsql-general
Benjamin Smith <lists@benjamindsmith.com> writes:
> The example that I gave was a small one to illustrate my understanding of
> multiple foreign keys, indexes and how they work together. (or don't) The
> actual query is quite a bit bigger and nastier. I've considered breaking it
> up into smaller pieces, but this query has been extensively tested and
> debugged. It's on a complex schema carefully designed to meet some very
> demanding requirements.

What you probably need to do is rethink the join order.  As coded, the
planner has no freedom to change the join order, which means it's up to
you to get it right.  In particular it seems a bad idea to be processing
the join to enrollments last when that table is the best-constrained
one.  Instead of "enrollments, stmoduleobjass LEFT JOIN lots-o-stuff"
consider "enrollments JOIN stmoduleobjass ON relevant-join-conditions
LEFT JOIN lots-o-stuff".  Likewise for lcregistrations vs lcclasses.

            regards, tom lane

pgsql-general by date:

Previous
From: Benjamin Smith
Date:
Subject: Re: Performance woes
Next
From: vishal saberwal
Date:
Subject: Re: File access problem access(), stat()