On Fri, 2007-09-21 at 16:26 +0200, Csaba Nagy wrote:
> Ok, I was not able to follow your explanation, it's too deep for me into
> what the planner does...
I'm thinking that this case is too narrow to do too much with, when I
think about how we might do what I proposed. OTOH this isn't the first
bad plan we've had because we used the index for ordering. There might
be some common link that we can improve upon.
> > Incidentally, the way out of this is to improve the stats by setting
> > stats target = 1000 on column a of ta. That will allow the optimizer to
> > have a better estimate of the tail of the distribution of a, which
> > should then be more sensibly reflected in the cost of the Index Scan.
> > That doesn't solve the actual problem, but should help in your case.
> OK, I can confirm that. I set the statistics target for column "a" on
> table_a to 1000, analyzed, and got the plan below. The only downside is
> that analyze became quite expensive on table_a, it took 15 minutes and
> touched half of the pages... I will experiment with lower settings,
> maybe it will work with less than 1000 too.
Well, we know there are ways of optimizing ANALYZE.
ISTM we should be able to auto-select stats target based upon the shape
of the frequency distribution of the column values. We'd need to make
some calculations about the index cost model, but its probably worth it
for the future.
In response to
pgsql-performance by date
|Next:||From: brauagustin-susc||Date: 2007-09-21 17:30:45|
|Subject: Re: Low CPU Usage|
|Previous:||From: Kevin Grittner||Date: 2007-09-21 16:35:15|
|Subject: Re: query io stats and finding a slow query|