Re: BUG #7853: Incorrect statistics in table with many dead rows.

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема Re: BUG #7853: Incorrect statistics in table with many dead rows.
Дата
Msg-id CAMkU=1z=bfSH5gg4UbNDo0B3vq1mLp0YVTf5KcQvYrz0XwFk3w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: BUG #7853: Incorrect statistics in table with many dead rows.  (James R Skaggs <james.r.skaggs@seagate.com>)
Список 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 по дате отправления:

Предыдущее
От: a_dursun@hotmail.com
Дата:
Сообщение: BUG #7913: TO_CHAR Function & Turkish collate
Следующее
От: Tom Lane
Дата:
Сообщение: Re: BUG #7913: TO_CHAR Function & Turkish collate