On 12 November 2013 21:41, Nicolas Barbier <nicolas.barb...@gmail.com> wrote:
> Look-up speed is as follows: Each look-up must look through all > B-trees. That can be optimised by using a min max approach, so we need only look at sub-trees that may contain data. > Index size: I think (didn’t calculate) that the combined size of the > B-trees will be about the same as (a little bit more than) the size of > a single big B-tree containing the same entries. Agreed > Major missing piece in PostgreSQL (I think): > > * Functionality to merge K indexes into one (bigger) combined index. Good analysis. I would add that it is possible to optimise large DELETEs from a table if complete sub-trees of the btree can be easily removed. This for me would be the compelling benefit of this approach. 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. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers