On Wed, Apr 30, 2025 at 02:43:41PM -0500, Sami Imseih wrote:
> I also want to add that the decision to not normalize the cursor name in
> the FETCH command is because it would not make sense to combine
> FETCH commands for various cursors into the same entry.
- calls | rows | query
--------+------+-------------------------------------------------------
- 2 | 0 | CLOSE cursor_stats_1
- 2 | 0 | DECLARE cursor_stats_1 CURSOR WITH HOLD FOR SELECT $1
+ calls | rows | query
+-------+------+----------------------------------------------------
+ 2 | 0 | CLOSE $1
+ 2 | 0 | DECLARE $1 CURSOR WITH HOLD FOR SELECT $2
Hmm. What are the workloads that you have seen as problematic? Do
these involve cursor names generated randomly, where most of them are
similar with a random factor for the name? Too much normalization
here would limit the amount of verbosity that we have for this area,
especially if we are dealing with query patterns that rely on few
CLOSE naming patterns spread across a couple of key queries, because
we would now know anymore about their distribution.
- 1 | 5 | FETCH FORWARD 5 pgss_cursor
- 1 | 7 | FETCH FORWARD ALL pgss_cursor
- 1 | 1 | FETCH NEXT pgss_cursor
+ 1 | 0 | DECLARE $1 CURSOR FOR SELECT * FROM pgss_matv
Saying that, applying normalization for the number of FETCH looks like
a natural move. It seems to me that we should still make a difference
with the ALL case, though?
typedef struct ClosePortalStmt
{
NodeTag type;
- char *portalname; /* name of the portal (cursor) */
+ /* name of the portal (cursor) */
+ char *portalname pg_node_attr(query_jumble_ignore);
+ ParseLoc location pg_node_attr(query_jumble_location);
/* NULL means CLOSE ALL */
Could it matter to make a distinction with CLOSE ALL, compared to the
case where the CLOSE statements are named? It would be possible to
make a difference compared to the named case with an extra boolean
field, for example. I would suggest to add some tests for CLOSE ALL
anyway; we don't have any currently.
--
Michael
