Re: pg_stat_statements query jumbling question

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pg_stat_statements query jumbling question
Дата
Msg-id 25151.1441083676@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: pg_stat_statements query jumbling question  (Satoshi Nagayasu <snaga@uptime.jp>)
Ответы Re: pg_stat_statements query jumbling question  (Satoshi Nagayasu <snaga@uptime.jp>)
Список pgsql-hackers
Satoshi Nagayasu <snaga@uptime.jp> writes:
> On 2015/09/01 13:41, Peter Geoghegan wrote:
>> If you want to use the queryId field directly, which I recall you
>> mentioning before, then that's harder. There is simply no contract
>> among extensions for "owning" a queryId. But when the fingerprinting
>> code is moved into core, then I think at that point queryId may cease
>> to be even a thing that pg_stat_statements theoretically has the right
>> to write into. Rather, it just asks the core system to do the
>> fingerprinting, and finds it within queryId. At the same time, other
>> extensions may do the same, and don't need to care about each other.
>> 
>> Does that work for you?

> Yes. I think so.

> I need some query fingerprint to determine query group. I want queryid
> to keep the same value when query strings are the same (except literal 
> values).

The problem I've got with this is the unquestioned assumption that every
application for query IDs will have exactly the same requirements for
what the ID should include or ignore.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: [PATCH] SQL function to report log message
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: [PATCH] SQL function to report log message