Re: High-Concurrency GiST in postgreSQL
От | Andy Colson |
---|---|
Тема | Re: High-Concurrency GiST in postgreSQL |
Дата | |
Msg-id | 4EDD1AFE.4020208@squeakycode.net обсуждение исходный текст |
Ответ на | High-Concurrency GiST in postgreSQL ("C. Mundi" <cmundi@gmail.com>) |
Ответы |
Re: High-Concurrency GiST in postgreSQL
|
Список | 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
В списке pgsql-general по дате отправления: