Re: pg_stat_statements fingerprinting logic and ArrayExpr

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: pg_stat_statements fingerprinting logic and ArrayExpr
Дата
Msg-id CAM3SWZQwUJYC1bVDJDoUy=3-0BAHvfArc90-HO5HoxDY7zvx=A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pg_stat_statements fingerprinting logic and ArrayExpr  (Andres Freund <andres@2ndquadrant.com>)
Ответы Re: pg_stat_statements fingerprinting logic and ArrayExpr
Список pgsql-hackers
On Tue, Dec 10, 2013 at 1:41 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> FWIW, I hit exactly this issue every single time I have looked at
> pg_stat_statements in some client's database making it nearly useless
> for analysis. So improving it might be worthwile.

I think the thing that makes me lean towards doing this is the fact
that pgFouine and pgBadger have been doing something similar for
years, and those tools continue to be much more popular than I thought
they'd be now that pg_stat_statements with normalization is fairly
widely available. Yes, of course the problem can be solved by using "
= ANY(array)". But some people are lazy, or uninformed, or they don't
directly control this. As I mentioned, this has traditionally been a
problem with Django, where I imagine the fix is non-trivial. I haven't
asked, but it isn't too hard to imagine that the Django guys are
probably not all that keen on doing a lot of work that will only be
applicable to Postgres.

Did you really find pg_stat_statements to be almost useless in such
situations? That seems worse than I thought.

I guess it in no small part comes down to what the long term future of
the query finger-printer is.

-- 
Peter Geoghegan



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: pg_stat_statements fingerprinting logic and ArrayExpr
Следующее
От: Andres Freund
Дата:
Сообщение: Re: pg_stat_statements fingerprinting logic and ArrayExpr