| From: | Sami Imseih <samimseih(at)gmail(dot)com> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Improve explicit cursor handling in pg_stat_statements |
| Date: | 2025-06-02 19:44:36 |
| Message-ID: | CAA5RZ0uSsSttonTemcOq69yHvftMtCRCmvTkAGAKsJtVNTWLig@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> > The FETCH and CLOSE are already not clear to what underlying SQL
> > they are referring to, and there is not much chance to actually
> > improve that unless
> > we track a cursor queryId in pg_stat_statements ( at that point we can show that
> > FETCH or CLOSE refer to this specific cursor statement ).
> I don't really have an issue for FETCH with the number as the name is
Since the FETCH case is clear-cut, here is a patch that normalizes variable
fetch sizes in a FETCH command. At a minimum, we can apply this patch.
I’ve also added tests in pg_stat_statements utility.sql to demonstrate
how queryIds
are grouped for the variants of the FETCH statement.
--
Sami Imseih
Amazon Web Services (AWS)
| Attachment | Content-Type | Size |
|---|---|---|
| v2-0001-Normalize-variable-fetch-sizes-in-a-FETCH-command.patch | application/octet-stream | 13.3 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2025-06-02 19:49:06 | Re: Correcting freeze conflict horizon calculation |
| Previous Message | Jeff Davis | 2025-06-02 19:42:35 | Re: Persist injection points across server restarts |