[postgis-users] GiST Concurrency Project : IMPORTANT
pramsey at refractions.net
Fri Jun 10 04:48:00 PDT 2005
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.
More information about the postgis-users