Re: Updating histogram_bounds after a delete - Mailing list pgsql-performance

From Kevin Grittner
Subject Re: Updating histogram_bounds after a delete
Date
Msg-id 4D80EBAB020000250003B9DE@gw.wicourts.gov
Whole thread Raw
In response to Updating histogram_bounds after a delete  (Derrick Rice <derrick.rice@gmail.com>)
Responses Re: Updating histogram_bounds after a delete
List pgsql-performance
Derrick Rice <derrick.rice@gmail.com> wrote:

> I recently ran into a problem with a planner opting for a
> sequential scan rather than a bitmap heap scan because the stats
> suggested that my delete query was going to affect 33% of the
> rows, rather than the 1% it really was.

> could possibly react by updating the histogram_bounds at
> commit-time, rather than needing an additional analyze or needing
> auto-analyze settings jacked way up.

I recommend you try version 9.0 with default autovacuum settings and
see how things go.  If you still have an issue, let's talk then.
Besides numerous autovacuum improvements, which make it more
reliable and less likely to noticeably affect runtime of your
queries, there is a feature to probe the end of an index's range in
situations where data skew was often causing less than optimal plans
to be chosen.

From what you've told us, I suspect you won't see this problem in
9.0 unless you shoot yourself in the foot by crippling autovacuum.

-Kevin

pgsql-performance by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: Re: Adding additional index causes 20,000x slowdown for certain select queries - postgres 9.0.3
Next
From: Fujii Masao
Date:
Subject: Re: pg_xlog size