On Thu, 27 Dec 2007, Tom Lane wrote:
Jeff Frost <jeff@xxxxxxxxxxxxxxxxxxxxxx> writes:
On Thu, 27 Dec 2007, Tom Lane wrote:
But note that as of 8.3, SELECT-only transactions won't acquire an
XID and hence won't advance the counter. So if you're thinking of
writing code that depends on that behavior, don't.
So, the new XID counter won't advance unless there's at least one
INSERT/UPDATE/DELETE in the transaction? Does it also update for SELECTs that
call a function which does some write activity?
Any "write" activity causes an XID to be acquired.
Is there a new counter (or old one that I don't know about) that keeps track
of the SELECT-only transactions?
There's no global counter. There's a backend-local "virtual transaction
id" counter.
That's a drag as I have quite a few clients who graph the xacts/sec with MRTG.
Most of these clients have read heavy workloads and it would be great to be
able to graph read vs write xacts, but a drag if you have no visibility into
the read xacts.
--
Jeff Frost, Owner <jeff@xxxxxxxxxxxxxxxxxxxxxx>
Frost Consulting, LLC http://www.frostconsultingllc.com/
Phone: 650-780-7908 FAX: 650-649-1954
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
