[postgis-users] IMPORTANT: (Still) Seeking Funding for Faster PostGIS Indexes

[Paul Ramsey]

Thanks to the sponsorship of Michigan Technological University, we now
have 50% of the work complete. There is a working patch at the
commitfest <https://commitfest.postgresql.org/action/patch_view?id=631>
which provides quad-tree and kd-tree indexes.

However, there is a problem: unless the patch is reviewed and goes
through more QA/QC, it'll never get into PostgreSQL proper. In case
you think I am kidding: we had a patch for KNN searching ready for the
9.0 release, but it wasn't reviewed in time, so we had to wait all the
way through the 9.1 cycle to get it.

I am looking for sponsors in the $5K to $10K range to complete this
work. If you use PostgreSQL in your business, this is a chance to add
a basic capability that may help you in all kinds of ways you don't
expect. We're talking about faster geospatial indexes here, but this
facility will also radically speed any partitioned space. (For
example, the suffix-tree, which can search through URLs incredibly
fast. Another example, you can use a suffix tree to very efficiently
index geohash strings. Interesting.)

If you think there's a possibility, please contact me and I will send
you a prospectus you can take to your manager. Let's make this happen
folks!

Paul

On Fri, May 27, 2011 at 10:45 AM, Paul Ramsey <pramsey at opengeo.org> wrote:
> One of the eye-opening talks of PgCon last week was the presentation
> from Oleg Bartunov and Teodor Sigaev on their work on spatial
> partitioning indexes in PostgreSQL. Oleg and Teodor are the
> maintainers of the GiST framework we use for our r-tree, and are
> proposing a new framework to allow quad-tree and kd-tree
> implementations in PostgreSQL.
>
> http://www.pgcon.org/2011/schedule/events/309.en.html
>
> The upshot is, this new approach is as much as 6-times faster than the
> r-tree (at least for points). If you're interested in seeing PostGIS
> indexes get vastly faster, consider funding this project. Get in touch
> with me directly for details.
>
> http://blog.opengeo.org/2011/05/27/pgcon-notes-3/
>
> P.
>