Re: Stats not updated after rollback -- autovacuum confused.

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: Stats not updated after rollback -- autovacuum confused.
Дата
Msg-id 200705170105.l4H158t05325@momjian.us
обсуждение исходный текст
Ответ на Stats not updated after rollback -- autovacuum confused.  ("Dawid Kuroczko" <qnex42@gmail.com>)
Ответы Re: Stats not updated after rollback -- autovacuum confused.  (Alvaro Herrera <alvherre@commandprompt.com>)
Список pgsql-hackers
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold

---------------------------------------------------------------------------

Dawid Kuroczko wrote:
> Hello, I have a system where there are mostly COPYs,
> which insert data into a table.  Ocasionally a COPY will fail (and thus,
> dead rows appear), but as far as I can tell ROLLBACK is not reflected
> anywhere in the pg_stats_user_tables.  And since there are no rows
> n_tup_upd or n_tup_del, therefore autovacuum will not fire for that table.
> 
> I see two possible solutions:
>  1) let rollback increment both n_tup_ins and n_tup_del (or maybe
>      n_tup_upd, at least)?  This would be a good safeguard, I guess.
> 
>  2) ANALYZE is able to see wether table is accumulating dead rows.
> It might be a good idea to make ANALYZE able hint autovacuum that
> some tables need VACUUM (that they exceed limits set for autovacuum).
> 
> The 2nd point could be a TODO item, perhaps?  Something like:
> When ANALYZE runs, make it note removable dead rows and non-removable
> dead rows.  If removable dead rows exceed some threshold, hint autovacuum
> at that table.
> 
>    Regards,
>        Dawid
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 7: You can help support the PostgreSQL project by donating at
> 
>                 http://www.postgresql.org/about/donate

--  Bruce Momjian  <bruce@momjian.us>          http://momjian.us EnterpriseDB
http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Jim C. Nasby"
Дата:
Сообщение: Re: Not ready for 8.3
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: temporal variants of generate_series()