Re: pg_stat_statements fingerprinting logic and ArrayExpr - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: pg_stat_statements fingerprinting logic and ArrayExpr
Date
Msg-id CAM3SWZQwUJYC1bVDJDoUy=3-0BAHvfArc90-HO5HoxDY7zvx=A@mail.gmail.com
Whole thread Raw
In response to Re: pg_stat_statements fingerprinting logic and ArrayExpr  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: pg_stat_statements fingerprinting logic and ArrayExpr
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_stat_statements fingerprinting logic and ArrayExpr
Next
From: Andres Freund
Date:
Subject: Re: pg_stat_statements fingerprinting logic and ArrayExpr