Re: Scalability in postgres

Jeff Janes <jeff(dot)janes(at)gmail(dot)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