On Tue, Jan 10, 2017 at 2:24 PM, Alvaro Herrera
<alvherre@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