On 24.04.2013 22:10, Michael Schuh wrote:
Thank you both for the very helpful feedback. Perhaps the scope of this project (application's "completeness criteria") is better as a feasibility prototyping of the global/distance-based index strategy with B+-tree and/or GiST extension possibilities.
For GSoC, we'd really like to see some code that can be committed as a result. Prototyping is important, but if that's all you do during the summer, the work is likely going to waste if no-one is going to work actively on the prototype afterwards.
At this point, I think we need a more concrete plan on how this would be implemented. The idea of using a regular B-tree for this, with some functions to do the partition mapping might work. However, that would be a clunky interface - I don't think that would be accepted into PostgreSQL. So I don't think that makes a good GSoC project.
If you think this can be done with the existing GiST or SP-GiST APIs, I'd like to see a more concrete plan on how that would work. What datatype would this be for? How would the partitioning be done? If the APIs need to be extended, what would the extensions look like? The summer is short, so there isn't much time for exploration - we need to have a pretty good idea of what the result will look like, right now.
- Heikki -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
