To: "Joshua Shanks" <jjshanks@gmail.com>
cc: "Craig Ringer" <craig@postnewspapers.com.au>,
	pgsql-performance@postgresql.org
Subject: Re: query planner not using the correct index 
In-reply-to: <84f0acdb0808070811l43a3da9eq240d272f8ddd105c@mail.gmail.com> 
References: <84f0acdb0808061435q5ebb607cjc311f1eb4da841a@mail.gmail.com>
	<489A623A.4090400@postnewspapers.com.au>
	<84f0acdb0808062014p29cf7482ied332225a0a92c63@mail.gmail.com>
	<489A6AF5.50908@postnewspapers.com.au>
	<84f0acdb0808070811l43a3da9eq240d272f8ddd105c@mail.gmail.com>
Comments: In-reply-to "Joshua Shanks" <jjshanks@gmail.com>
	message dated "Thu, 07 Aug 2008 10:11:43 -0500"
Date: Thu, 07 Aug 2008 17:12:40 -0400
Message-ID: <27696.1218143560@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"Joshua Shanks" <jjshanks@gmail.com> writes:
> It seems obvious that the stats on attr1 at the current level are
> inaccurate as there are over 100,000 unique enteries in the table.

Well, you haven't told us how big any of these tables are, so it's
hard to tell if the n_distinct value is wrong or not ... but in
any case I don't think that the stats on attr1 have anything to do
with your problem.  The reason that the "fast" query is fast is that
it benefits from the fact that there's only one bars row with
bars_id = 12345.  So the question is how many such rows does the
planner now think there are (try "explain analyze select * from bars
where bars_id = 12345"), and if it's badly wrong, then you need to be
looking at the stats on bars.bars_id to find out why.

			regards, tom lane