On Jan 6, 2008 11:27 AM, <tomas(at)tuxteam(dot)de> 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, <tomas(at)tuxteam(dot)de> wrote:
> > >
> > > One thought I had back then, with partitioned tables was "gee --
> > > index is already doing a partition; why do a manual partition on top
> > > 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
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.
In response to
pgsql-hackers by date
|Next:||From: Joshua D. Drake||Date: 2008-01-06 08:40:56|
|Subject: Bug: Unreferenced temp tables disables vacuum to update xid|
|Previous:||From: Gokulakannan Somasundaram||Date: 2008-01-06 08:17:01|
|Subject: Re: Dynamic Partitioning using Segment Visibility Maps|