Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Sergey Koposov <koposov(at)ast(dot)cam(dot)ac(dot)uk>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Florian Pflug <fgp(at)phlo(dot)org>, Merlin Moncure <mmoncure(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile
Date: 2012-05-31 02:00:23
Message-ID: 20120531020023.GB1267@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert,

* Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
> On Wed, May 30, 2012 at 9:10 PM, Sergey Koposov <koposov(at)ast(dot)cam(dot)ac(dot)uk> wrote:
> > I understand the need of significant locking when there concurrent writes,
> > but not when there only reads. But I'm not a RDBMS expert, so that's maybe
> > that's misunderstanding on my side.
>
> If we knew in advance that no writes would come along during the
> execution of a particular test case, then we could skip a lot of
> locking on the reads. But we don't, so we have to be prepared for the
> possibility of writes at any time, which means doing things taking
> share-locks on data while it's actively being read.

Uh, we have a read-only transaction mode, don't we? Or does that not
help, because someone else, in another transaction, could take a
read-write lock?

Thanks,

Stephen

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2012-05-31 02:03:00 Re: Uppercase tab completion keywords in psql?
Previous Message Florian Pflug 2012-05-31 01:59:17 Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile