Re: [HACKERS] WARM and indirect indexes - Mailing list pgsql-hackers

From Craig Ringer
Subject Re: [HACKERS] WARM and indirect indexes
Date
Msg-id CAMsr+YH_mSsrJaxscFhpwA=dkWmo0nGDsAQ__u1j+ko4+6Gf2w@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] WARM and indirect indexes  (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>)
List pgsql-hackers


On 11 Jan. 2017 21:29, "Andrew Dunstan" <andrew.dunstan@2ndquadrant.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.

pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: [HACKERS] plpgsql - additional extra checks
Next
From: Marko Tiikkaja
Date:
Subject: Re: [HACKERS] plpgsql - additional extra checks