Re: Why won't it index scan?

From: "Ed L(dot)" <pgsql(at)bluepolka(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Why won't it index scan?
Date: 2006-05-17 20:07:24
Message-ID: 200605171407.24332.pgsql@bluepolka.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Wednesday May 17 2006 1:26 pm, Tom Lane wrote:
> "Ed L." <pgsql(at)bluepolka(dot)net> writes:
> > I'm trying to understand what happened here, and I have a
> > theory.
>
> The problem is the horrid misestimation of the selectivity of
> "nursestation_key = 40":
>
> -> Bitmap Index Scan on
> idx_visit_nursestation_key (cost=0.00..69.35 rows=4956
> width=0) (actual time=0.158..0.158 rows=6 loops=1) Index Cond:
> (nursestation_key = 40)
>
> When you're off by a factor of 800+ on the number of matching
> rows, you're going to arrive at a less than optimal plan.
> Increasing the stats target on visit.nursestation_key would be
> the solution.

Ok, makes sense.

So, does this sound like we just happened to get repeatedly
horribly unrepresentative random samples with stats target at
10? Are we at the mercy of randomness here? Or is there a
better preventive procedure we can follow to systematically
identify this kind of situation?

Ed

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tony Caduto 2006-05-17 20:28:45 PG_DIAG_STATEMENT_POSITION Where is it defined?
Previous Message Tom Lane 2006-05-17 19:34:28 Re: autovacuum "connections" are hidden