On Mon, May 11, 2026 at 02:13:27PM +0800, Chao Li wrote: > Then the query text is shown as the normalized “fetch $1 c”. This > seems incorrect to me, because the representative query text should > not depend on the execution order of FETCH statements.
This is an incorrect expectation. These query patterns are grouped together because they are represented the same way at their Node level after deparsing, and PGSS uses the first query string it finds when inserting the data of a query into a new slot. Specifying only a cursor name means a forward fetch with FETCH_KEYWORD_NONE, for one tuple. Specifying an integer (with or without from_in) and a cursor name means a forward fetch with FETCH_KEYWORD_NONE, for a specified number of tuples. The whole point is to normalize around the number of tuples all these queries. Both queries mean the same thing, once FetchStmt.howMany is moved into the "ignore" area of query jumbling. > The attached patch tries to fix this by adding a query_normalized > flag to pgssEntry, which records whether the stored representative > query text is already normalized. With this flag, if FETCH c is > executed first and stores an unnormalized query string, a later > FETCH 2 c can replace it with the normalized query string. Nope, I don't think that this is something we need to act on. Note that adding an extra generate_normalized_query() is not an acceptable thing to do: this has a performance impact and we don't want to make PGSS heavier than it is today. So it is inefficient, for one. The correct thing to do if we'd want to make the difference between the two cases would be to add a new value to FetchDirectionKeywords, and assign that to the "cursor_name" and "from_in cursor_name" case (say a new FETCH_KEYWORD_SINGLE?) in gram.y. I don't think that we need to do something here as this does not really represent a gain in terms of monitoring (aka more normalization is better to me here), but the new value would be the correct thing to do if it happens that folks want this difference to show up. -- Michael
signature.asc
Description: PGP signature
