Re: Scalability in postgres

Jeff Janes <jeff.janes@gmail.com> writes:
> I apologize if it is bad form to respond to a message that is two
> months old, but I did not see this question answered elsewhere and
> thought it would be helpful to have it answered.  This my rough
> understanding.  Oracle never "takes" a snapshot, it computes one the
> fly, if and when it is needed.  It maintains a structure of recently
> committed transactions, with the XID for when they committed.  If a
> process runs into a tuple that is neither from the future nor from the
> deep past, it consults this structure to see if that transaction has
> committed, and if so whether it did so before or after the current
> query was started.  The structure is partionable so it does not have
> one global lock to serialize on, and the lock is short as it only gets
> the info it needs, not the entire set of global open transactions.

Are you sure it's partitionable?  I've been told that Oracle's
transaction log is a serious scalability bottleneck.  (But I think
I first heard that in 2001, so maybe they've improved it in recent
releases.)  We know that Postgres' WAL log is a bottleneck --- check
for recent discussions involving XLogInsert.  But the WAL log is
only touched by read-write transactions, whereas in Oracle even
read-only transactions often have to go to the transaction log.

            regards, tom lane