Re: Incorrect accounting (n_tup_ins) of non-inserted rows

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Incorrect accounting (n_tup_ins) of non-inserted rows
Дата
Msg-id 15621.1458307531@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Incorrect accounting (n_tup_ins) of non-inserted rows  (Ilya Matveychikov <matvejchikov@gmail.com>)
Ответы Re: Incorrect accounting (n_tup_ins) of non-inserted rows  (Ilya Matveychikov <matvejchikov@gmail.com>)
Список pgsql-bugs
Ilya Matveychikov <matvejchikov@gmail.com> writes:
> Seems that accounting of insertions with `n_tup_ins` not correct in
> case of insertion errors cause by constraints checking (duplicate key
> value violates unique constraint):

You already found one of the many code comments indicating that this is
the intended behavior:

> CODE REFERENCE (src/backend/postmaster/pgstat.c)
> /* count attempted actions regardless of commit/abort */

> So, is this behavior normal or probably needs to be fixed?

No, it's not a bug, and it's not going to be fixed.  For many of the
intended applications of those counts (e.g, determining whether
autovacuum/autoanalyze is needed), this is the correct behavior
and ignoring actions of failed transactions would be incorrect.

The live/dead tuple counts do attempt to take transaction success
into account; perhaps looking at those would be more helpful for
your use-case?

            regards, tom lane

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

Предыдущее
От: Ilya Matveychikov
Дата:
Сообщение: Incorrect accounting (n_tup_ins) of non-inserted rows
Следующее
От: Tom Lane
Дата:
Сообщение: Re: BUG #13750: Autovacuum slows down with large numbers of tables. More workers makes it slower.