From: | Andy Colson <andy(at)squeakycode(dot)net> |
---|---|
To: | "C(dot) Mundi" <cmundi(at)gmail(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: High-Concurrency GiST in postgreSQL |
Date: | 2011-12-05 19:26:54 |
Message-ID: | 4EDD1AFE.4020208@squeakycode.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 12/5/2011 12:31 PM, C. Mundi wrote:
>
> Hello. This is my first post. As such, feedback on style and choice of
> venue are especially welcome.
>
> I am a regular but not especially expert user of a variety of databases,
> including postgreSQL.
> I have only modest experience with spatial databases.
>
> I have a new project[1] in which GiST could be very useful, provided I
> can achieve high concurrency.<SNIP>
concurrency here can mean different things. One application hitting PG
which then uses multiple threads? (Not currently possible) Or one app
with multiple threads each having a database connection? (Which is
really the same as) Multiple app's each having a database connection?
PG limits one database connection to one cpu. Multiple connections will
use multiple cpu.
OR, by concurrency, do you mean, non-blocking? And if you mean
non-blocking, is that for read's, write's, or both?
In PG you can do non-blocking, multiple connections (ie multiple cpu),
reads as much as you want.
Extending to indexes: many connections can read a gist index at the same
time. Is that what you need?
-Andy
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-12-05 20:00:57 | Re: disallow SET WORK_MEM |
Previous Message | Bruce Momjian | 2011-12-05 19:13:58 | Re: disallow SET WORK_MEM |