On Tue, Mar 19, 2019 at 1:24 PM Jim Finnerty <jfinn...@amazon.com> wrote: > The queryId depends on oids, so it is not stable enough for some purposes. > For example, to create a SQL identifier that survives across a server > upgrade, or that can be shipped to another database, the queryId isn't > usable. > > The apg_plan_mgmt extensions keeps both its own stable SQL identifier as > well as the queryId, so it can be used to join to pg_stat_statements if > desired. If we were to standardize on one SQL identifier, it should be > stable enough to survive a major version upgrade or to be the same in > different databases.
If Amazon would like to open-source its (AIUI) proprietary technology for computing query IDs and propose it for inclusion in PostgreSQL, cool, but I think that is a separate question from whether people would like more convenient access to the query ID technology that we have today. I think it's 100% clear that they would like that, even as things stand, and therefore it does not make sense to block that behind Amazon deciding to share what it already has or somebody else trying to reimplement it. If we need to have a space for both a core-standard query ID and another query ID that is available for extension use, adding one more field to struct Query, so we can have both coreQueryId and extensionQueryId or whatever, would be easy to do. It appears that there's more use case than I would have guessed for custom query IDs. On the other hand, it also appears that a lot of people would be very, very happy to just be able to see the query ID field that already exists, both in pg_stat_statements in pg_stat_activity, and we shouldn't throw up unnecessary impediments in the way of making that happen, at least IMHO. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
