Re: No longer possible to query catalogs for index capabilities? - Mailing list pgsql-hackers

On Wed, Aug 10, 2016 at 5:14 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Kevin Grittner <kgrittn@gmail.com> writes:

>> Where [whether the AM supports predicate locking at a
>> granularity finer than the provided default of index relation]
>> would be interesting to know is [ ... ] (when there is more than
>> just btree supported, so it is not so easy to remember) if you
>> are a DBA investigating a high rate of serialization failures
>> and want to know whether indexes of a certain type have
>> index-relation predicate locking granularity or something more
>> fine-grained.  [This] use case seems plausible once there is
>> more of a mix of support among the AMs.
>
> TBH, that line of thought impresses me not at all, because I do not see
> a reason for SQL queries to need to see internal behaviors of AMs, and
> especially not at levels as crude as boolean properties of entire AMs,
> because that's just about guaranteed to become a lie (or at least not
> enough of the truth) in a year or two.

But a DBA who has a problem doesn't care what the truth will be in
a year or two -- the interest is in *right now* on one particular
cluster.

> If you are a DBA wanting to know how fine-grained the locking is
> in a particular index type, you really need to read the source code
> or ask a hacker.

Really?

> 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.  So, the
next question is, if it is somewhat likely to become useful as an
exposed property in some future release, are we better off exposing
it now, even though it might not be referenced much, or wait until
we see demand popping up on the lists by people needing the
information to solve problems they are having?

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company