Thread: Re: [HACKERS] WARM and indirect indexes
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. -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 11 Jan. 2017 21:29, "Andrew Dunstan" <andrew.dunstan@2ndquadrant.com> wrote:
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.
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.
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.
On Wed, Jan 11, 2017 at 08:28:28AM -0500, Andrew Dunstan 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. Right, and we do make such arguments --- what is your point? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +