From: | Yann Michel <yann-postgresql(at)spline(dot)de> |
---|---|
To: | Greg Stark <gsstark(at)mit(dot)edu> |
Cc: | Hannu Krosing <hannu(at)tm(dot)ee>, Andre Maasikas <andre(at)abs(dot)ee>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: plans for bitmap indexes? |
Date: | 2004-10-27 14:44:12 |
Message-ID: | 20041027144412.GA21431@uff.spline.inf.fu-berlin.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On Wed, Oct 27, 2004 at 10:13:56AM -0400, Greg Stark wrote:
>
> There's a logical separation between the idea of index methods and table
> storage mechanisms. Trying to implement something like this that breaks that
> abstraction will only make things far more confusing.
>
> I think what you're trying to accomplish is better accomplished through
> partitioned tables. Then the user can decide which keys to use to partition
> the data and the optimizer can use the data to completely exclude some
> partitions from consideration. And it wouldn't interfere with indexes to
> access the data within a partition.
this is not always the truth. In datawarehouosing applications you often
use data paritioning (time based) and bitmap indexes for fast
star-transformations. A very efficient way to solve that ist using
bitmap indexes.
Regards,
Yann
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2004-10-27 14:50:19 | Re: rmtree() failure on Windows |
Previous Message | Reini Urban | 2004-10-27 14:44:07 | src/timezone/pgtz __imp__my_exec_path |