On Tue, Nov 12, 2013 at 6:41 PM, Nicolas Barbier <nicolas.barb...@gmail.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 <si...@2ndquadrant.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). -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
