[Fwd: Re: [GENERAL] Unisersal B-Tree]

Started by Justin Cliftover 24 years ago2 messages
#1Justin Clift
justin@postgresql.org

Hi all,

Not sure if this is useful, but it might be good to file and reference
somewhere.

Regards and best wishes,

Justin Clift

-------- Original Message --------
Subject: Re: [GENERAL] Unisersal B-Tree
Date: Mon, 30 Apr 2001 17:59:49 +0200
From: J�rg Schulz <jschulz@sgbs.de>
Organization: Geb�udereinigung Schulz
To: "Justin Clift" <justin@postgresql.org>
References: <9cb797$642$1@news.tht.net>
<3AEB9B33.EA886A2B@postgresql.org> <001b01c0d143$b9b33f40$0600a8c0@opal>
<3AED60D9.37A9028A@postgresql.org>

Do you mind if I forward this email to the pgsql-hackers@postgresql.org
mailing list?

Of cource you can forward it. Maybe you can correct my bad english :-)

J�rg Schulz

----- Original Message -----
From: "Justin Clift" <justin@postgresql.org>
To: "J�rg Schulz" <jschulz@sgbs.de>
Sent: Monday, April 30, 2001 2:55 PM
Subject: Re: [GENERAL] Unisersal B-Tree

Show quoted text

Hi J�rg,

I know we have indices and sub-indices, but this also sounds
interesting.

Do you mind if I forward this email to the pgsql-hackers@postgresql.org
mailing list?

Regards and best wishes,

Justin Clift

J�rg Schulz wrote:

Hi Cliff,

I've read an article in the german magazine c't (2001/1 P174) about this
new astonishing method. After I realized that none of the major commercial
databases implement this for now (afaik there is only one database on the
market "Transbase HyperCube" www.transaction.de), I thought it would be a great
chance for an open source database. I even think it's a "must have feature"
in the near future.

But what is it about? It can dramatically speed up queries that run over more
than one index. Think of a query like this:

select a,b,c from table where ( a>min_a and a<max_a ) and ( b>min_b and b<max_b )

In a conventional implementation you have two indexes on attributes a and b.
But to run this query the database engine profits only from one index. It has
to run through all the values of the other. This gets even worse if you use more
constraints, and this scheme is typical for things like OLAP.

With the new methode you add one UB-index that embraces a and b. And you run
only once through this index.

There are a number of papers available under mistral.in.tum.de that explain
the basic concepts.

Regards,

J�rg Schulz

----- Original Message -----
From: "Justin Clift" <justin@postgresql.org>
To: "JXrg Schulz" <jschulz@sgbs.de>
Sent: Sunday, April 29, 2001 6:40 AM
Subject: Re: [GENERAL] Unisersal B-Tree

Hi J�rg,

What advantages do they have?

Regards and best wishes,

Justin Clift

JXrg Schulz wrote:

Are there any plans to implement UB-Trees
multidimensional indexes?

J�rg Schulz

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://www.postgresql.org/search.mpl

--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi

--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Justin Clift (#1)
Re: [Fwd: Re: [GENERAL] Unisersal B-Tree]

... Think of a query like this:

select a,b,c from table where ( a>min_a and a<max_a ) and ( b>min_b and b<max_b )

In a conventional implementation you have two indexes on attributes a and b.
But to run this query the database engine profits only from one index. It has
to run through all the values of the other. This gets even worse if you use more
constraints, and this scheme is typical for things like OLAP.

With the new methode you add one UB-index that embraces a and b. And you run
only once through this index.

And this is different from a multicolumn btree index how?

I looked at the referenced website when this message first went by,
and was unhappy at the apparently proprietary nature of the technology
(not to mention the excessive hype ratio). I lost interest ...

regards, tom lane