From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Justin Clift <justin(at)postgresql(dot)org> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [Fwd: Re: [GENERAL] Unisersal B-Tree] |
Date: | 2001-05-04 19:56:10 |
Message-ID: | 27662.989006170@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> ... 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
From | Date | Subject | |
---|---|---|---|
Next Message | Ken Hirsch | 2001-05-04 19:58:07 | Re: Re: New Linux xfs/reiser file systems |
Previous Message | Lamar Owen | 2001-05-04 19:49:58 | Re: Packaging 7.1.1 |