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