RE: pgsql is 75 times faster with my new index scan
От | Mikheev, Vadim |
---|---|
Тема | RE: pgsql is 75 times faster with my new index scan |
Дата | |
Msg-id | 8F4C99C66D04D4118F580090272A7A23018D20@SECTORBASE1 обсуждение исходный текст |
Ответ на | pgsql is 75 times faster with my new index scan (devik@cdi.cz) |
Список | 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
В списке pgsql-hackers по дате отправления: