> > postgres_fdw, as an example, in which cursor name get reused > > for different queries. Notice below "c1" and "c2" is reused for different > > queries, so now what underlying sql is FETCH, i.e. FETCH 100 FROM c1 > > referring > > to? v2-0001 does not help us with the FETCH problem > > because as I mentioned we don't have access to the underlying sql > > ( and parsing is even too early to do a portal lookup to find the > > underlying sql to > > base the queryId on). What v2-0001 will do is at least group the DECLARE > > CURSOR > > statements together for cursors referencing the same query and reduce the # > > of entries. > > This case relies on postgres_fdw's GetCursorNumber() that assigns a > unique number for a cursor, ensuring uniqueness per connection within > a transaction, and the counter is reset at the end of the > transactions. So good point for this case that this hurts. If that > holds for the most common cases where this is seen as bloating pgss, > that brings some solid ground, especially more for applications that > use many cursor numbers in long-ish transactions states done under > postgres_fdw.
Sorry for the delayed response. I’ve been thinking about this a bit, and I agree that it’s really hard to get a good sense of the use cases out there. postgres_fdw does have the issue of reusing cursor names, which renders the stats essentially meaningless, in my opinion—not to mention it contributes to excessive bloat. Looking at a driver like psycopg, explicit cursors are supported through the driver, but the user must define the name of the cursor, so it's much more controlled. I really wonder if the right answer is to have a pg_stat_statements.track_cursor_utility GUC that can toggle the reporting of utility statements related to explicit cursors, while still tracking the underlying statements. I would even suggest making 'on' the default to maintain the current behavior. I don’t like that we have to introduce a new GUC for this, but I can't think of a better alternative. Thoughts? -- Sami Imseih Amazon Web Services (AWS)
