On Jan 6, 2008 11:27 AM, <[EMAIL PROTECTED]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Sun, Jan 06, 2008 at 01:12:32AM +0530, Gokulakannan Somasundaram wrote: > > On Jan 5, 2008 6:15 PM, <[EMAIL PROTECTED]> wrote: > > > > > > > > One thought I had back then, with partitioned tables was "gee -- > B-tree > > > index is already doing a partition; why do a manual partition on top > of > > > that?". > > > Can you please explain more on what you are trying to say here? > > Sure. A B-tree is just a device to partition something along some order. > If you have , say, a table of orders (to use the example upthread) and a > B-tree index on order date, this index partitions your set (at > recursively finer levels).
But the current index scans - Index Scan and Bitmap Index Scan, doesn't provide the exact benefit of partitioning, even if all the columns are covered by the index. It does a lot more disk reads than the partitioning scheme. I think you are looking for something like Block indexes in Multi-dimensional Clusters in DB2. Heikki did something like that in a more subtle way. Postgresql Clusters, as you may know doesn't maintain the order with inserts. We might go for Index Organized Tables/Clustered indexes. But then, B-tree would give lot of performance problems, if the Index Tuple size increases beyond a certain point. Thanks, Gokul.
