Re: Updating histogram_bounds after a delete

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Kenneth Marshall" <ktm(at)rice(dot)edu>
Cc: "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-17 15:05:02
Message-ID: 4D81DCCE020000250003BA27@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Kenneth Marshall <ktm(at)rice(dot)edu> wrote:

> I think this is it:
>
>
http://archives.postgresql.org/pgsql-committers/2010-01/msg00021.php

Looks like it. Based on the commit date, that would be a 9.0
change. Based on the description, I'm not sure it fixes Derrick's
problem; the workaround of explicitly using min() for the low end of
a range may need to be a long-term approach.

It does seem odd, though, that the statistics would be off by that
much. Unless the query is run immediately after a mass delete,
autovacuum should be fixing that. Perhaps the autovacuum
improvements in later releases will solve the problem. If not, an
explicit ANALYZE (or perhaps better, VACUUM ANALYZE) immediately
after a mass delete would be wise.

-Kevin

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Jeff 2011-03-17 15:13:58 Xeon twice the performance of opteron
Previous Message Tom Lane 2011-03-17 15:00:59 Re: Updating histogram_bounds after a delete