[postgis-users] GiST Concurrency Project : IMPORTANT

Gregory S. Williamson gsw at globexplorer.com
Sat Jun 11 01:51:55 PDT 2005

I am all in favor of this, and am trying to get the company which employs my labor time to commit some resources to this ... don't be discouraged by a lack of immediate response, please. It's just that, uhm, bean counters can be notoriously hard to persuade even if the utility and cost effectiveness of the solution is clear to those of who use these tools.

If only the DBA, Chief Information Officer and other such titles carried more weight !

Greg WIlliamson
GLobeXplorer LLC
-----Original Message-----
From:	postgis-users-bounces at postgis.refractions.net on behalf of Paul Ramsey
Sent:	Fri 6/10/2005 4:48 AM
To:	PostGIS Users Discussion
Subject:	Re: [postgis-users] GiST Concurrency Project : IMPORTANT

Just an update. There are 700 people on this mailing list currently.  
As of this morning, I have received zero (0) responses on this.

An explanation of why this is important: currently, when doing an  
update or delete to a stable with a GiST index (any indexed PostGIS  
table) PostgreSQL must obtain a FULL TABLE LOCK. That means only one  
update can go in at a time. That means that if you are querying a  
table at the same time someone is updating it, things slow down.  
Basically it means in terms of handling concurrent data  
modifications, GiST tables (PostGIS tables) are an order of magnitude  
less effective than b-tree tables (non-spatial tables). We have found  
that with just two (2) developers working on a large spatial  
database, it is possible for them to step on each others toes by  
doing large updates on spatial tables. One starts an update, and  
suddenly the other finds some of her queries that use that table are  
blocking and delaying. Eventually, if you use PostGIS for tasks that  
involve data modification, you *will* run into this problem.

This is a huge opportunity to improve the core on which PostGIS is  
built. If you are thinking "we don't need this now, and if we need it  
later we will come up with the money and have it done then", you are  
making strategic error. Right now, there is an opportunity to pool  
your funds with others and pay a lot less for very high end  
functionality: later, there may not be a pool.  Right now, there are  
experienced, brilliant developers ready to start on the work, and  
when you need the functionality, it will be there: later, they may  
not be available, and even if they are it will take them months to  
complete the work.  Later, will you be able to afford the delay?

This is not a sales pitch, this is a customer pitch. Like you, we are  
a heavy *user* of PostGIS, that is why we are willing to put up our  
own money for this improvement. If you need invoices for accounting  
purposes, we can act as a middle man. If you do not, then by all  
means, contact Oleg and Teodor directly. But as a community, we are  
really coming up short if we cannot make this one happen.


On 7-Jun-05, at 7:56 PM, Paul Ramsey wrote:

> PostGIS'ers,
> Oleg and Teodor are ready to attack GiST concurrency, so the time  
> has come for all enterprise PostGIS users to dig deep and help fund  
> this project.
> http://archives.postgresql.org/pgsql-hackers/2005-06/msg00294.php
> Refractions Research will contribute $2000 towards this development  
> project, and will serve as a central bundling area for all funds  
> contributed towards this project. As such, we will provide invoices  
> that can be provided to accounts payable departments and cash  
> cheques on North American banks to get the money oversees to Oleg  
> and Teodor. No, we will not assess any commisions for this: we want  
> to see this done.
> GiST concurrency will allow more granular locking for spatial table  
> updates, inserts and deletes, and will provide improved performance  
> for all users with multi-user systems doing data management. We in  
> the PostGIS project have done all we can to get the most out of the  
> existing GiST structure, but now we have to help the experts make  
> GiST even better.
> Please contact me on or off list, whatever you are comfortable  
> with. I hope that everyone who needs this functionality can find  
> $1-5K to contribute towards getting this done for 8.1.

postgis-users mailing list
postgis-users at postgis.refractions.net


More information about the postgis-users mailing list