Re: [survey] New "Stable" QueryId based on normalized query text
От | Julien Rouhaud |
---|---|
Тема | Re: [survey] New "Stable" QueryId based on normalized query text |
Дата | |
Msg-id | CAOBaU_Z-5HZQ5Zc71pj0NdshD4vBy84nj8q+Zok37XhHpu7MpA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [survey] New "Stable" QueryId based on normalized query text (Evgeniy Efimkin <efimkin@yandex-team.ru>) |
Список | 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 по дате отправления: