Re: BUG #8681: column 'n_tup_del' of pg_stat_user_tables doesn't change in case of truncate
От | Rod Taylor |
---|---|
Тема | Re: BUG #8681: column 'n_tup_del' of pg_stat_user_tables doesn't change in case of truncate |
Дата | |
Msg-id | CAKddOFAOJnDLM-Jde=Y_k8QK6GLVJk1fe_EQRGnYK-42zEH=5A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #8681: column 'n_tup_del' of pg_stat_user_tables doesn't change in case of truncate (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: BUG #8681: column 'n_tup_del' of pg_stat_user_tables doesn't change in case of truncate
|
Список | pgsql-bugs |
It's still an interesting question. Why doesn't truncate reset table statistic to 0? The table state prior to a truncate shouldn't influence vacuum or necessity after the truncate. Not that vacuuming a recently truncated table would be expensive, but Analyze timing is a concern. regards, Rod On Mon, Dec 16, 2013 at 10:50 AM, Stephen Frost <sfrost@snowman.net> wrote: > Anit, > > * Anit Chakkarwar (anitchakkarwar@gmail.com) wrote: > > Now n_tup_del = 2, n_tup_ins=120, n_live_tup=20 in pg_stat_user_tables, > but > > how can I figure out what has happened to 98 rows? > > This is information for statistics- if you need an accurate count, > you'll need to use a trigger and track that information explicitly.. > There can be other ways that n_tup_del can end up being inexact. > > Thanks, > > Stephen >
В списке pgsql-bugs по дате отправления: