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

> > 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