Re: Updating histogram_bounds after a delete

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Derrick Rice" <derrick(dot)rice(at)gmail(dot)com>, <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Updating histogram_bounds after a delete
Date: 2011-03-16 21:56:11
Message-ID: 4D80EBAB020000250003B9DE@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Derrick Rice <derrick(dot)rice(at)gmail(dot)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

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Fujii Masao 2011-03-17 03:09:20 Re: pg_xlog size
Previous Message Tech Madhu 2011-03-16 21:27:17 Re: pg_xlog size