Re: Improve explicit cursor handling in pg_stat_statements

> > 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)