On Tue, Oct 5, 2010 at 5:05 PM, Oleg Bartunov <o...@sai.msu.su> wrote: > Are you sure postgres doesn't have limitation at all ? There are a lot ot > them. Of course, there are limitation and limitation and we should avoid > limitations, which will require incompatible changes in future in user's > code, or which prevent future improvements (getting rid limitation). We > suggested implementation of k-nn search, which has limitations, but in my > opinion, they are rather small and doesn't prevent in future to > write a descent patch, based on your five-key syscaches patches, > which will touch a lot of places in the pg source. > > Who need boolean distance ? Ok, you insisted, we now support it. Teodor > wrote arguments > (http://archives.postgresql.org/message-id/4c8e2590.6040...@sigaev.ru) > why two fields solution doesn't really helped. > > You want "the points most distant from the bright center of the universe?", > sorry, for now. I think, this is a limitation we can live with for now. It's > k-nearest neighbourhood search, and not k-furthest outliers search. > > You want documentation for review, I don't believe a reviewer can't review > without users documentation like CREATE/ALTER OPERATOR CLASS, etc. Andrew > Gierth was true, > that GiST documentation needed to be rewritten and he suggested to do that > if I understand him. I'd love to help, but I don't have any message from > him. > If he changed his mind, I'll describe these changes. > > We're not full-time pg-employers and it's not easy for us to follow new > cleaner-way. I think there is a risk, that there are will be lesser big > features introduced by non-pg employers in the future and eventually, pg > will be open-source database developed by pg-employers with some amount > cosmetic changes and fixes. > > I suggest to find a sensible consensus on implementation, taking into > account Pareto Rule, and leave place for future improvement.
I am sorry my review pissed you off, as it seems to have done. Looking back on it, I realize now that it was phrased more harshly than it needed to be. That having been said, it seems to me that we really are at an impasse and I am not sure what to propose as a way forward. Tom and I laid out a technical design back in January and I still think it's a good one, even though I know you think it's silly. We may just have to agree to disagree on this point. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers