Skip site navigation (1) Skip section navigation (2)

Re: Scalability in postgres

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Scalability in postgres
Date: 2009-08-14 23:21:58
Message-ID: 1261.1250292118@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-performance
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

In response to

Responses

pgsql-performance by date

Next:From: NickolayDate: 2009-08-15 08:11:14
Subject: Re: Per-database warm standby?
Previous:From: Alvaro HerreraDate: 2009-08-14 22:09:49
Subject: Re: Per-database warm standby?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group