Horton

Re: queryId constant squashing does not support prepared statements

Jeremy Schneider <schneider@ardentperf.com>

View thread
From: Jeremy Schneider <schneider@ardentperf.com>
To: Álvaro Herrera <alvherre@kurilemu.de>
Cc: Michael Paquier <michael@paquier.xyz>, Dmitry Dolgov <9erthalion6@gmail.com>, Sami Imseih <samimseih@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-05-06T02:44:03Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix typo in comment

  2. Make query jumbling also squash PARAM_EXTERN params

  3. Fix squashing algorithm for query texts

  4. pg_stat_statements: Fix parameter number gaps in normalized queries

On Fri, 2 May 2025 14:56:56 +0200
Álvaro Herrera <alvherre@kurilemu.de> wrote:

> On 2025-May-02, Michael Paquier wrote:
> 
> > That depends.  If we conclude that tracking this information through
> > the parser based on the start and end positions in a query string
> > for a set of values is more relevant, then we would be redesigning
> > the facility from the ground, so the old approach would not be
> > really relevant..  
> 
> I disagree that a revert is warranted for this reason.  If you want to
> change the implementation later, that's fine, as long as the user
> interface doesn't change.
> 

FWIW, i'm +1 on leaving it in pg18. Prepared statements often look a
little different in other ways, and there are a bunch of other quirks
in how queryid's are calculated too. Didn't there used to be something
with CALL being handled as a utility statement making stored procs look
different from functions?



-- 
To know the thoughts and deeds that have marked man's progress is to
feel the great heart throbs of humanity through the centuries; and if
one does not feel in these pulsations a heavenward striving, one must
indeed be deaf to the harmonies of life.

Helen Keller. Let Us Have Faith. Doubleday, Doran & Company, 1940.