Mark Mielke wrote:
Where does the expectation come from? I don't recall ever reading it in
the documentation, and unless the session processes are contending over
the integers (using some sort of synchronization primitive) in memory
that represent the "latest visible commit" on every single select, I'm
wondering how it is accomplished?
The "integers" you're imagining are the ProcArray. Every backend has an
entry there, and among other things it contains the current XID the
backend is running. When a backend takes a new snapshot (on every single
select in read committed mode), it locks the ProcArray, scans all the
entries and collects all the XIDs listed there in the snapshot. Those
are the set of transactions that were running when the snapshot was
taken, and is used in the visibility checks.
> If they are contending over these
> integers, doesn't that represent a scaling limitation, in the sense that
> on a 32-core machine, they're going to be fighting with each other to
> get the latest version of these shared integers into the CPU for
> processing? Maybe it's such a small penalty that we don't care? :-)
The ProcArrayLock is indeed quite busy on systems with a lot of CPUs.
It's held for such short times that it's not a problem usually, but it
can become a bottleneck with a machine like that with all backends
running small transactions.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
