Kevin Grittner <kgri...@gmail.com> writes: > That one seems like it should either be at the AM level or not > included at all. Where it would be interesting to know is if you > are a hacker looking for an AM to enhance with support, or (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. The latter 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. 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. We have been bit by the "representation not good enough to describe actual behavior" problem *repeatedly* over the years that pg_am had all this detail. First it was amstrategies and amsupport, which have never usefully described the set of valid proc/op strategy numbers for any index type more complicated than btree. Then there was amorderstrategy, which we got rid of in favor of amcanorder, and later added amcanbackward to that (not to mention amcanorderbyop). And amconcurrent, which went away for reasons I don't recall. Then we added amstorage, which later had to be supplemented with amkeytype, and still isn't a very accurate guide to what's actually in an index. amcanreturn actually was a boolean rather than a function for awhile (though it looks like we never shipped a release with that definition). There's still a lot of stuff with obviously limited life expectancy, like amoptionalkey, which is at best a really crude guide to what are valid index qualifications; someday that will likely have to go away in favor of a "check proposed index qual for supportability" AM callback. So I don't think I'm being unreasonable in wanting to minimize, not maximize, the amount of info exposed through this interface. There is enough history to make me pretty sure that a lot of things that might be simple boolean properties today are going to be less simple tomorrow, and then we'll be stuck having to invent arbitrary definitions for what the property-test function is going to return for those. And if there are any queries out there that are depending on simplistic interpretations of those property flags, they'll be broken in some respect no matter what we do. 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". regards, tom lane -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers