=?utf-8?q?Milos_Gajdos?= <gy2kre@xxxxxxxxxx> writes: > What this shows is that xact_commit increases by 3 after just one row insert. tup_inserted does seem to report correct value. After simple SELECT, xact_commit increases by 2 - kind of strange as SELECT shouldn't really be increasing xact_commit ? Yes, a SELECT does count as an xact_commit. What I think is confusing you is that the commit isn't reported to the stats collector right away unless there are some database-local table access counts to send too. And fetching from pg_stat_database doesn't result in any such accesses. So each SELECT results in a local increment of the commit counter but you won't see it in the stats until after you do an INSERT, or otherwise do something that involves a countable access to a database-local table. I do see what seems to be a bug, which is that the "Don't expend a clock check" short-circuit at the top of pgstat_report_stat() needs to not fire if "force" is true. That looks like it could result in never counting a session's last few transactions at all. But that's not what's affecting you here, it's the intentional optimization to delay sending transaction counts. regards, tom lane -- Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
