Simon Riggs wrote > Minmax indexes seem to surprise many people, so broad generalisations > aren't likely to be useful. > > I think the best thing to do is to publish some SQL requests that > demonstrate in detail what you are trying to achieve and test them > against minmax indexes. That way we can discuss what does work and > what doesn't work well enough yet.
While I do believe in testing (since "In theory there is no difference between theory and practice. In practice there is"), I would like to know the "properties" of the minmax index before trying it. What is it supposed to be good at? What are the pros/cons? We can't ask all the users to just "try" the index and see if it works for them. As I said, my understanding is that is very efficient (both in insertion and in searching) when data is somehow ordered in the table. But maybe I got it wrong... Anyway, the sql scenario is simple: a table with 4 bigint indexes; data in the fields is a random bigint in the range 1-10000000. Insertion is 5-10K rows/second. One search every 1-5 seconds, by one of the indexed fields (only equality, no range). There's also an index on a timestamp field, but that's not random so it doesn't give that many problems (it's actually the one where I wanted to try the minmax). -- View this message in context: http://postgresql.1045698.n5.nabble.com/Fast-insertion-indexes-why-no-developments-tp5776227p5776976.html Sent from the PostgreSQL - hackers mailing list archive at Nabble.com. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers