From: | Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Brad Nicholson <bnichols(at)ca(dot)afilias(dot)info>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: autovacuum and immediate shutdown issues |
Date: | 2009-10-19 18:26:26 |
Message-ID: | dcc563d10910191126g2ce64beeve9cb7001a3c0220f@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Mon, Oct 19, 2009 at 11:27 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> writes:
>> All of this is completely besides the point that a database that's
>> been shutdown immediately / had the power cord yanked comes back up
>> and doesn't start autovacuuming automatically, which seems a
>> non-optimal behaviour.
>
> It'll start as soon as you've modified enough rows. The absolute worst
> case behavior is that table bloat reaches twice the level it would have
> otherwise, or pg_statistic data becomes twice as out of date as it would
> have otherwise.
That could be a pretty bad worst case scenario for certain types of
tables / usage patterns.
How bad can the affect of out of date pg_statistic data be? Is it
likely to turn a hash agg into a nested loop and take a query from
seconds to minutes? If so, then that's pretty bad.
> Now, if your server's MTBF is less than the autovac interval, you could
> indeed have an accumulating problem ... but I suggest that in that
> situation you've got other issues to fix.
True. Still very much beside the point.
From | Date | Subject | |
---|---|---|---|
Next Message | Christophe Pettus | 2009-10-19 18:35:31 | Re: autovacuum and immediate shutdown issues |
Previous Message | Tom Lane | 2009-10-19 18:02:28 | Re: Function returning 2 columns evaluated twice when both columns are needed |