[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 !
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:
> 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.
> 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