Re: Fast insertion indexes: why no developments

On Tue, Nov 12, 2013 at 6:41 PM, Nicolas Barbier
<nicolas(dot)barbier(at)gmail(dot)com> wrote:
> (Note that K B-trees can be merged by simply scanning all of them
> concurrently, and merging them just like a merge sort merges runs.
> Also, all B-trees except for the first level (of size S) can be
> compacted 100% as there is no need to reserve space for further
> insertions in them.)

Unless you can guarantee strong correlation of index-order vs
physical-order, scanning multiple indexes in index-order will be quite
slow (random I/O).

On Tue, Nov 12, 2013 at 7:14 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> I still think we need to look at this from a query perspective though.
> We need to check whether there is a class of real world queries that
> are not well optimised by minmax indexes, or cannot be made to be in
> future releases. For example, large DELETEs from a table are almost
> trivially optimised for min max.

Only if you don't have a PK (or other index).