Kevin Grittner <kgrittn@gmail.com> writes:
> On Wed, Aug 10, 2016 at 5:14 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> In short, I do not see a good reason to expose ampredlocks at the SQL
>> level, and I think there needs to be a darn good reason to expose any of
>> this stuff, not just "maybe some DBA will think he needs to query this".
> As I said before, there's probably not a lot of benefit exposing it
> *now*, when only btree indexes support fine-grained predicate
> locks; but if we were to add support for one or two more AMs per
> release for the next several releases, it could become a
> significant benefit to a DBA who's trying to figure out a problem
> -- especially if that DBA is not a skilled C programmer.
By then, we might have a better idea of whether a per-AM boolean flag is a
sensible long-term representation or not. Right now, I say that this does
little except lock us into something we may well wish to get out of.
Also, I'm very skeptical of the implied position that pg_am properties
should explain everything a DBA needs to know about the different AMs.
That's never been even remotely true, and if that's the sort of standard
we wish to strive for, an API that can return a few boolean properties
ain't gonna cut it. I think we should limit our ambitions here to
exposing properties that *applications* demonstrably have uses for.
regards, tom lane
