From: Tom Lane <tgl@sss.pgh.pa.us>
To: Marty Frasier <m.frasier@escmatrix.com>
cc: pgsql-performance@postgresql.org, James Quinn <j.quinn@escmatrix.com>
Subject: Re: how to help the planner
In-reply-to: 
 <CAAX5s64o2LCF0cWNqDMTiM1JuSyyESvh1T1QW1cmDTpi4n2rdg@mail.gmail.com>
References: 
 <CAAX5s64o2LCF0cWNqDMTiM1JuSyyESvh1T1QW1cmDTpi4n2rdg@mail.gmail.com>
Comments: In-reply-to Marty Frasier <m.frasier@escmatrix.com>
	message dated "Thu, 28 Mar 2013 11:59:05 -0400"
Date: Thu, 28 Mar 2013 12:18:46 -0400
Message-ID: <868.1364487526@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

Marty Frasier <m.frasier@escmatrix.com> writes:
> We've been using postgreSQL for a few years.  This is my first post here
> and first real dive into query plans.

One quick thought is that it's probably worth cranking up
join_collapse_limit and/or from_collapse_limit, since the number of
relations in the query is considerably more than the default values of
those limits.  This will make planning take longer but possibly find
better plans.  I'm not sure it will help a lot, since most of the
problem is evidently bad rowcount estimates, but it might help.

Also it seems like the major rowcount failing is in the estimate for the
t12 subquery.  I can't tell why that particular combination of WHERE
clauses is giving it such a hard time --- is there something odd about
the distribution of 'cahsee_ela' tests?  Why is that particular subquery
grouped over school/student when all the others are grouped over just
student?

			regards, tom lane


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance