Re: query planner not using the correct index

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Joshua Shanks" <jjshanks(at)gmail(dot)com>
Cc: "Craig Ringer" <craig(at)postnewspapers(dot)com(dot)au>, pgsql-performance(at)postgresql(dot)org
Subject: Re: query planner not using the correct index
Date: 2008-08-07 21:12:40
Message-ID: 27696.1218143560@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

"Joshua Shanks" <jjshanks(at)gmail(dot)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

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Scott Marlowe 2008-08-07 21:30:13 Re: file system and raid performance
Previous Message Tom Lane 2008-08-07 21:01:47 Re: Query Plan choice with timestamps