Re: WARM and indirect indexes

On 11 Jan. 2017 21:29, "Andrew Dunstan" <andrew(dot)dunstan(at)2ndquadrant(dot)com>
wrote:

On 01/10/2017 09:25 PM, Bruce Momjian wrote:

> I am not saying we shouldn't do it, but I am afraid that the complexity
> in figuring out when to use indirect indexes, combined with the number
> of users who will try them, really hurts its inclusion.
>
>

I think you're making this out to be far more complex than it really is.
You could argue the same about a great many features. Both of these
features have upsides and downsides.

Obviously we need to get some benchmarks to we can quantify the effects,
but this complexity argument doesn't convince me at all. After all, nobody
has to use indirect indexes.

Another consideration is ... say we decide it didn't work out in the real
world and doesn't see enough use, has needed more maintenance than
expected, etc. Unlikely IMO but allow that for the sake of argument.

Well... this is something we can rip out.

It's not something that'll deeply and permanently change fundamentals of
the on-disk heap representation. It doesn't add new data types we can't
easily remove. It's... just not that intrusive. Especially from a
UI/application PoV.

So our *risk* here isn't that great either. Our commitment doesn't have to
be total. There aren't semantic differences that we will break apps by
undoing if we decided to change how they worked behind the scenes, drop the
idea entirely, etc.

Sure, we'll have them in supported releases for a while even in the VERY
unlikely event that happens. But it's not like there's much code churn
there, much cost to a little used feature.

All that said, I'm far from convinced this will be niche or little used.
Nor does it look hugely intrusive or likely to be a maintenance burden. So
the cost side of the cost/benefit/risk analysis isn't exactly overwhelming.