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-coremachine, they're going to be fighting with each other to> get the latest version of these shared integers into
theCPU 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
