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

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile
Дата
Msg-id 20120531020023.GB1267@tamriel.snowman.net
обсуждение исходный текст
Ответ на Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile  (Jeff Janes <jeff.janes@gmail.com>)
Список pgsql-hackers
Robert,

* Robert Haas (robertmhaas@gmail.com) wrote:
> On Wed, May 30, 2012 at 9:10 PM, Sergey Koposov <koposov@ast.cam.ac.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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Florian Pflug
Дата:
Сообщение: Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Uppercase tab completion keywords in psql?