From: | Derrick Rice <derrick(dot)rice(at)gmail(dot)com> |
---|---|
To: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Updating histogram_bounds after a delete |
Date: | 2011-03-17 13:27:41 |
Message-ID: | AANLkTikrVqwXp3ugoMLR8-6BOegSDByRCuTCFtGVBZ+E@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Wed, Mar 16, 2011 at 5:56 PM, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov
> wrote:
> 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.
>
Was this introduced in 9.0 or was it earlier? My company hasn't introduced
integrated support for 9.0 yet, but I can go to 8.4.
It was suggested that I change my SQL from:
delete from my_table where event_date < now() - interval '12 hours';
to:
delete from my_table where event_date < now() - interval '12 hours'
and event_date >= (select min(event_date) from my_table);
Which, even if the stats are out of date, will be more accurate as it will
not consider the histogram buckets that are empty due to previous deletes.
Seems like exactly what the feature you mentioned would do, no?
Thanks for the help,
Derrick
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Andreasen | 2011-03-17 14:25:16 | Fastest pq_restore? |
Previous Message | tv | 2011-03-17 09:34:54 | Re: Help with Query Tuning |