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_YMOF_9aGwm+ryE=3KxLWfOFH3Zddr-dsMt2xNwRA1XtQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [survey] New "Stable" QueryId based on normalized query text  (legrand legrand <legrand_legrand@hotmail.com>)
Ответы Re: [survey] New "Stable" QueryId based on normalized query text  (legrand legrand <legrand_legrand@hotmail.com>)
Список pgsql-hackers
On Wed, Mar 20, 2019 at 10:18 PM legrand legrand
<legrand_legrand@hotmail.com> wrote:
>
> On my personal point of view, I need to get the same Queryid between (OLAP)
> environments
> to be able to compare Production, Pre-production, Qualif performances
> (and I don't need Fully qualified relation names). Today to do that,
> I'm using a custom extension computing the QueryId based on the normalized
> Query
> text.

IIUC, your need is to compare pgss (maybe other extensions) counters
from different primary servers, for queries generated by the same
application(s).  A naive workaround like exporting each environment
counters (COPY SELECT 'production', * FROM pg_stat_statements TO
'...'), importing all of them on a server and then comparing
everything using the query text (which should be the same if the
application is the same) instead of queryid wouldn't work?  Or even
using foreign tables if exporting data is too troublesome. That's
clearly not ideal, but that's an easy workaround which doesn't add any
performance hit at runtime.


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

Предыдущее
От: Shaun Thomas
Дата:
Сообщение: Re: Re: A separate table level option to control compression
Следующее
От: Julien Rouhaud
Дата:
Сообщение: Re: [survey] New "Stable" QueryId based on normalized query text