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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-performance by date

  From Date Subject
Next Message Nickolay 2009-08-15 08:11:14 Re: Per-database warm standby?
Previous Message Alvaro Herrera 2009-08-14 22:09:49 Re: Per-database warm standby?