Re: [survey] New "Stable" QueryId based on normalized query text - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Re: [survey] New "Stable" QueryId based on normalized query text
Date
Msg-id CAOBaU_Z-5HZQ5Zc71pj0NdshD4vBy84nj8q+Zok37XhHpu7MpA@mail.gmail.com
Whole thread Raw
In response to Re: [survey] New "Stable" QueryId based on normalized query text  (Evgeniy Efimkin <efimkin@yandex-team.ru>)
List pgsql-hackers
On Mon, Aug 12, 2019 at 4:01 PM Evgeniy Efimkin <efimkin@yandex-team.ru> wrote:
>
> > One problem with pg_stat_statement's normalized query is that it's not
> > stable, it's storing the normalized version of the first query string
> > passed when an entry is created. So you could have different strings
> > depending on whether the query was fully qualified or relying on
> > search path for instance.
> I think normalized query stored in pg_stat_statement it's not very important.
> it might look something like that
> `
>          query         | calls |  queryid   |  sql_id
> -----------------------+-------+------------+------------
>  Select * from   t     |     4 |  762359559 |  680388963
>  select * from t       |     7 | 3438533065 |  680388963
>  select * from test2.t |     1 |  230362373 |  680388963
> `
> we can cut schema name in sql normalization
> algorithm

Not only schema name but all kind of qualification and indeed extra
whitespaces. Things get harder for other difference that aren't
meaningful (LIKE vs ~~, IN vs = ANY...).  That would also imply that
everyone wants to ignore schemas in query normalization, I'm not sure
how realistic that is.



pgsql-hackers by date:

Previous
From: Evgeniy Efimkin
Date:
Subject: Re: [survey] New "Stable" QueryId based on normalized query text
Next
From: "Jonathan S. Katz"
Date:
Subject: Re: Add "password_protocol" connection parameter to libpq