Re: Fast insertion indexes: why no developments

> Another point to add: I don't really see btree as a barrier to
> performance for most of the problems I face.  The real barriers to
> database performance are storage, contention, and query planning.

Ehm that's true for regular OLTP stuff, which I understand is what most (95%?) of people use/need. But if you try to
insertrows into a 50M table with a couple of indexes, btrees just can't keep up.  
Of course, you can't have it all: fast at big table insertion, good contention, good query times...

> Postgres btreee indexes are pretty fast and for stuff like bulk
> insertions there are some optimization techniques available (such as
> sharding or create index concurrently).


At the moment I'm relying on partitioning + creating indexes in bulk on "latest" table (the partitioning is based on
time).But that means K*log(N) search times (where K is the number of partitions). 
That's why I gave a look at these different indexing mechanisms.