On Tue, Jan 10, 2017 at 2:24 PM, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > The big advantage of WARM is that it works automatically, like HOT: the > user doesn't need to do anything different than today to get the > benefit. With indirect indexes, the user needs to create the index as > indirect explicitely.
However, this cuts both ways. If the WARM implementation has bugs -- either data-corrupting bugs or crash bugs or returns-wrong-answer bugs or performance-in-corner-cases bugs -- everyone will be exposed to them. The kinds of things that could go wrong here are in my view very similar to the sorts of things that went wrong with multixacts. If indirect indexes turn out to have similar problems, that's sad, but people can decide not to use them and be no worse off than before. (This is exactly why parallel query is now provoking periodic griping rather than howls of agony - it's off by default in 9.6, and even if you turn it on, the costing defaults are set fairly conservatively, and even if it goes completely haywire due to some horrible bug, it's very unlikely to break anything for longer than it takes you to shut it back off. It's possible that WARM bugs would only mess up your indexes and not your table data, which is a lot less bad, but things that touch the on-disk format are near the top of my "this is scary" list.) More broadly, I don't share Bruce's negativity about indirect indexes. My estimate of what needs to be done for them to be really useful is - I think - higher than your estimate of what needs to be done, but I think the concept is great. I also think that some of the concepts - like allowing the tuple pointers to have widths other than 6 byes - could turn out to be a good foundation for global indexes in the future. In fact, it might be considerably easier to make an indirect index span a partitioning hierarchy than it would be to do the same for a regular index. But regardless of that, the feature is good for what it offers today. As to WARM, it scares me a lot. If zero serious data-corrupting bugs survive to final release, or even if no more than one or two do, and if it improves performance in general in the way some of the offered benchmarks indicate, fantastic. But a feature of this type is by its nature prone to eating your data in varied and subtle ways. Caveat committer. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers