| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | matvejchikov(at)gmail(dot)com |
| Cc: | pgsql-bugs(at)postgresql(dot)org |
| Subject: | Re: Incorrect accounting (n_tup_ins) of non-inserted rows |
| Date: | 2016-03-18 13:25:31 |
| Message-ID: | 15621.1458307531@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Ilya Matveychikov <matvejchikov(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2016-03-18 13:39:34 | Re: BUG #13750: Autovacuum slows down with large numbers of tables. More workers makes it slower. |
| Previous Message | daniel | 2016-03-18 12:24:47 | BUG #14033: cross-compilation to ARM fails |