Re: Incorrect accounting (n_tup_ins) of non-inserted rows - Mailing list pgsql-bugs

From Ilya Matveychikov
Subject Re: Incorrect accounting (n_tup_ins) of non-inserted rows
Date
Msg-id CAKh5naZqAL8yVG+8JVCB3DtQiwhq3FafXKpFtb18o-H5gKxzaA@mail.gmail.com
Whole thread Raw
In response to Re: Incorrect accounting (n_tup_ins) of non-inserted rows  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
2016-03-18 16:25 GMT+03:00 Tom Lane <tgl@sss.pgh.pa.us>:
> 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.
>

Thank you for clarifying.

> 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?

I'll take a look on that counters, thanks.

pgsql-bugs by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: BUG #14031: Failed to Write to History File
Next
From: David Gould
Date:
Subject: Re: BUG #13750: Autovacuum slows down with large numbers of tables. More workers makes it slower.