On Wed, Aug 10, 2016 at 6:14 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > 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".
I don't think you're being unreasonable, but I don't agree with your approach. I think that we should expose everything we reasonably can, and if we have to change it later then it will be a backward compatibility break. Making it unqueryable in the hopes that people won't try to query it is futile. -- Robert Haas EnterpriseDB: 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
