Re: UB-Tree - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: UB-Tree
Date
Msg-id 001101c1c8f3$379c8fe0$1600000a@tm.ee
Whole thread Raw
In response to UB-Tree  (Robert Schrem <robert.schrem@WiredMinds.de>)
List pgsql-hackers
----- Original Message -----
From: "Robert Schrem" <robert@schrem.de>
To: "Hannu Krosing" <hannu@krosing.net>
Cc: "PostgreSQL Hackers List" <pgsql-hackers@postgresql.org>
Sent: Monday, March 11, 2002 11:55 AM
Subject: Fwd: Re: [HACKERS] UB-Tree
> On Friday 08 March 2002 20:37, Hannu Krosing  wrote:
> > They may also have patents on it, so we should move carefully here.
>
> I sent a mail asking R. Bayer about any known patent issues.
> He said that the UB-Tree is internationally patented.
> Sad, because it looked like a briliant idea. Now it looks like
> it will be banned from the open source community for some
> decades to come... :-(

IANAL, but there seem to be some issues :

1. There is no such thing as 'internationally patented' as most countries
still don't allow patenting software algorithms.

2. I doubt it is possible to patent a general idea, like replacing multiple
one-dimensional indexes with one multi-dimensional index (conceptually
they _are_ the same thing, just optimised for different access paterns)

So as we can't use UB-Tree, we may well achieve similar result buy
using a multi-dimensional/multi-type R-tree and teach our optimiser
to use it for resolving multiple where clause restrictions simultaneously.

Of course this too may be patented. If it is not, let's hope this e-mail
will be archived and can be used as prior art to prevent future patenting
attempts :)

Another common way of fighting such patent's is patenting all possible
future improvements and then haggle with the patent holder .

I think this could be something that is effectively doable by open-source
community, at least the part of generating the ideas.

-------------
Hannu







pgsql-hackers by date:

Previous
From: "info"
Date:
Subject: FW: Re: [JDBC] DB mirroring
Next
From: Darren King
Date:
Subject: Re: select max(column) not using index