Re: BUG #7853: Incorrect statistics in table with many dead rows. - Mailing list pgsql-bugs

From Jeff Janes
Subject Re: BUG #7853: Incorrect statistics in table with many dead rows.
Date
Msg-id CAMkU=1z=bfSH5gg4UbNDo0B3vq1mLp0YVTf5KcQvYrz0XwFk3w@mail.gmail.com
Whole thread Raw
In response to Re: BUG #7853: Incorrect statistics in table with many dead rows.  (James R Skaggs <james.r.skaggs@seagate.com>)
List pgsql-bugs
On Fri, Feb 22, 2013 at 3:41 PM, James R Skaggs
<james.r.skaggs@seagate.com>wrote:

> Okay, I have some more info.
>
> Some background info.  This one table gets so many changes, I CLUSTER it
> each night.  However, after I do this. The statistics still appear to be
> incorrect.  Even after I do a "select pg_stat_reset();" Followed by 3
> ANALYZE at default_statistics_target as 1, 10, and 100
>
>     select relname, n_live_tup, n_dead_tup, n_tup_ins, n_tup_del,
> n_tup_hot_upd
>         from pg_stat_all_tables
>     ('stream_file', 109061143L, 103913868L, 0L, 14201L, 0L)
>
> Is it possible that there are still dead tuples after a CLUSTER?
>

Yes.  A cluster must bring along any tuples which are possibly visible to
any open transaction.  Your root problem seems to be that you have
long-open transactions which are preventing vacuum from doing its thing,
which leads you try clustering, but the long-open transaction prevents that
from doing its things effectively as well.

Perhaps PG could deal with this situation more gracefully, but
fundamentally you have to figure why you have these ancient transactions
lying around, and fix them or kill them.

Cheers,

Jeff

pgsql-bugs by date:

Previous
From: a_dursun@hotmail.com
Date:
Subject: BUG #7913: TO_CHAR Function & Turkish collate
Next
From: Tom Lane
Date:
Subject: Re: BUG #7913: TO_CHAR Function & Turkish collate