Re: knngist - 0.8 - Mailing list pgsql-hackers

On Tue, Oct 5, 2010 at 5:05 PM, Oleg Bartunov <oleg@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.6040802@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