On Wed, Aug 10, 2016 at 5:14 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Kevin Grittner <kgri...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
