From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Milos Gajdos <gy2kre(at)centrum(dot)cz> |
Cc: | pgsql-admin(at)postgresql(dot)org |
Subject: | Re: Postgres 9.1 statistics in pg_stat_database |
Date: | 2013-02-07 19:05:00 |
Message-ID: | 17450.1360263900@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
=?utf-8?q?Milos_Gajdos?= <gy2kre(at)centrum(dot)cz> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Steve Crawford | 2013-02-07 19:24:06 | Re: Postgres 9.1 statistics in pg_stat_database |
Previous Message | Milos Gajdos | 2013-02-07 18:16:41 | Postgres 9.1 statistics in pg_stat_database |