Re: High-Concurrency GiST in postgreSQL - Mailing list pgsql-general

From John R Pierce
Subject Re: High-Concurrency GiST in postgreSQL
Date
Msg-id 4EDD3A9B.6040802@hogranch.com
Whole thread Raw
In response to Re: High-Concurrency GiST in postgreSQL  ("C. Mundi" <cmundi@gmail.com>)
Responses Re: High-Concurrency GiST in postgreSQL  (Andy Colson <andy@squeakycode.net>)
List pgsql-general
On 12/05/11 1:34 PM, C. Mundi wrote:
> So that's my concern.  I'm doing 80% reads which are all non-blocking
> with 20% writes mixed in, and I need to avoid the effect of writes
> blocking queries which do not need to traverse branches affected by
> the write.

postgres does no blocking on inserts/updates.  the commonest lock is if
you're doing a transaction, and need to select something prior to
updating it, then you use a SELECT ... FOR UPDATE; this locks just the
rows you're going to update so noone else can update them (but other
clients can still read the existing value prior to your COMMIT).

--
john r pierce                            N 37, W 122
santa cruz ca                         mid-left coast


pgsql-general by date:

Previous
From: "C. Mundi"
Date:
Subject: Re: High-Concurrency GiST in postgreSQL
Next
From: John R Pierce
Date:
Subject: Re: High-Concurrency GiST in postgreSQL