[postgis-users] GiST Concurrency Project : IMPORTANT

[Paul Ramsey]

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.

Paul

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.