[postgis-users] GiST Concurrency Project : IMPORTANT

[Paul Ramsey]

Further update. I have received a number of statements of "interest in 
principle" and one PayPal donation, but no official major corporate 
contributions yet (aside from Refractions own $2000).

In the next two weeks, I will prepare a short prospectus for 
presentation to managers and accountants for those who need one.

On the PayPal front: I have checked with Oleg, and PayPal is not 
available in Russia (it only takes a few bad apples, I guess) so direct 
donations via that facility are out. For those who want to make a minor 
donation via PayPal, you can send contributions to my account 
(pramsey at refractions.net) and I will bundle them and do a direct deposit 
into Oleg's bank account with the rest of the funds when the project is 
complete. As with the larger "corporate" contributions, I can arrange 
for receipts or invoices for PayPal contributions if desired.

Yours,

Paul

Paul Ramsey wrote:

> 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.
> 
> 
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users