From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Oleg Bartunov <oleg(at)sai(dot)msu(dot)su> |
Cc: | Teodor Sigaev <teodor(at)sigaev(dot)ru>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: knngist - 0.8 |
Date: | 2010-10-05 22:38:28 |
Message-ID: | AANLkTikT5fDNXAgZqDi2mun0ozzAqfHXzQq4UdztEzpL@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Oct 5, 2010 at 5:05 PM, Oleg Bartunov <oleg(at)sai(dot)msu(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2010-10-05 22:40:40 | Re: Issues with Quorum Commit |
Previous Message | Josh Berkus | 2010-10-05 22:14:22 | Re: Issues with Quorum Commit |