RE: pgsql is 75 times faster with my new index scan

From: "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM>
To: "'devik(at)cdi(dot)cz'" <devik(at)cdi(dot)cz>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: RE: pgsql is 75 times faster with my new index scan
Date: 2000-09-27 21:46:33
Message-ID: 8F4C99C66D04D4118F580090272A7A23018D20@SECTORBASE1
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> > Why not implement *true* CLUSTER?
> > With cluster, all heap tuples will be in cluster index.
>
> It would be nice. It's pity that pg AMs are not general.
> There is no simple way to use btree instead of heap. But
> it would help.
> But using values from index is good idea too because you
> can have table with many columns and aggregate query which
> needs only two columns.
> The it will be MUCH faster to create secondary index which
> is much smaller than heap and use values from it.

Agreed. But this will add 16 bytes (2 xid + 2 cid) to size of btitems.
Currently, total size of btitem for 2-int4 key index is 16 bytes =>
new feature will double size of index and increase # of levels
(obviously bad for mostly static tables).

So, this feature should be *optional*...

> Vadim where can I found some code from upcoming WAL ?
> I'm thinking about implementing special ranked b-tree
> which will store precomputed aggregate values (like
> cnt,min,max,sum) in btree node keys. It can be then
> used for extremely fast evaluation of aggregates. But
> in case of MVCC it is more complicated and I'd like
> to see how it would be affected by WAL.

MVCC will not be affected by WAL currently. It's issue
of storage manager, not WAL.

Vadim

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Mikheev, Vadim 2000-09-27 22:03:30 RE: pgsql is 75 times faster with my new index scan
Previous Message Mikheev, Vadim 2000-09-27 20:14:53 RE: Re: function crashes backend